On Jan 05 2017, Sean Whitton <spwhit...@spwhitton.name> wrote: > Dear Nikolaus, > > On Wed, Jan 04, 2017 at 09:44:14AM -0800, Nikolaus Rath wrote: >> No, that's a misunderstanding. >> >> "The information I need" is the Debian-specific modifications to the >> current upstream source, separated into logically independent patches. >> >> Having separate patches in debian/patches gives me this information very >> quickly. >> >> Having to run git log, and then to manually merge the the commits gives >> me the same information, but it is not "very quickly". >> >> >> This is the drawback of the single-debian-patch approach. The fact that >> the patches are available in individual Git commits no longer helps >> after a few merges. > > Thanks for your reply. I see what you mean. > > The difference between our approachs seems to be whether we do the > semantic work up front, when making an upload, or later, when extracting > information by means of `git log` and `git diff`.
But, as far as I can tell, doing this work up-front is much easier: When using git-dpm or gbp-pq, the tool will present you with the conflicts separately for each Debian-modification that is being rebased. Resolving the conflicts is the only work you have to do. If you do the work later, then you start with a bunch of commits, any of which potentially contains parts of multiple Debian modifications. It is not clear how me how you would go about untangling them in a systematic way. 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