On Jan 03 2017, Sean Whitton <spwhit...@spwhitton.name> wrote: > Hello Russ, > > On Mon, Jan 02, 2017 at 09:29:24AM -0800, Russ Allbery wrote: >> Furthermore, it forces a rebased, clean representation of the patches, >> which I for one hugely prefer to the mess that you get if someone was >> packaging in Git and just randomly commits things directly to the >> packaging branch intermixed with merges from upstream. A few releases >> done that way will leave you almost completely unable to extract a rebased >> patch set against the current upstream source. (I have made this mistake >> so many times with my own packages.) > > Aside from `git debcherry`, which was already mentioned, git itself can > get you this information. For example: > > git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian' > > This will get you all commits which touched the upstream source that > have not been merged upstream. There can be as many merge commits as > you like in between.
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. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
signature.asc
Description: PGP signature