On Jan 05 2017, Sean Whitton <spwhitton@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.«
Attachment:
signature.asc
Description: PGP signature