Hello, On Tue, Jan 03, 2017 at 10:39:33AM -0800, Nikolaus Rath wrote: > > > > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian' > > Yes, but that's not as useful as what git-debcherry produces. > > For example, if you get a merge conflict when rebasing, the above > incantation will list two commits: the original debian commit and the > merge commit. git-debcherry, on the other hand, will synthesize one > patch, consisting of the original Debian commit, but modified to include > the *relevant parts* of the merge commit. That's a good point. In this context, `git debcherry` is a tool to filter and neaten a git history. However, it inserts another step between upstream, and powerful tools like git-cherry-pick and git-bisect. Upstream now has to know that Debian has orig.tars and various ways of representing changes to them. If I were a busy upstream, I would much rather `git fetch` my Debian maintainer's branches, and then immediately set to work cherry-picking and bisecting. I don't need any Debian-specific knowledge, except that which is relevant to the bug I'm trying to fix -- I don't need to know what an orig.tar is. This is worth having to look at a few merge commits. On Tue, Jan 03, 2017 at 10:54:07AM -0800, Russ Allbery wrote: > Well, if we had one more thing: a patches.debian.org service that would > show the git-debcherry-extracted patches against upstream. I really like > being able to just point upstream at all the patches relevant to them that > Debian has applied. That would be great. Then the git-debcherry series would be available for those that want it, without requiring package maintainers to do any curation at all. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature