Re: Preferred git branch structure when upstream moves from tarballs to git

[Sam Hartman <hartmans@debian.org>]

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> Ansgar Burchardt writes ("Re: Preferred git branch structure
    Ian> when upstream moves from tarballs to git"):
    >> Sam Hartman <hartmans@debian.org> writes: > OK, I didn't hear
    >> that as an answer but think I'm coming to the same > conclusion
    >> that Ian did after reading your mail.  > It sounds like you are
    >> talking about having the Debian packaging in a > separate
    >> repository from upstream.  > Do I correctly understand the model
    >> you are talking about?
    Ian> ...
    >> I'll point to [1] for what complexity this avoids.  Try
    >> explaining that to someone without advanced Git knowledge...
    >> 
    >> [1]
    >> https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html

    Ian> I am getting increasingly unhappy with your tone, and with the
    Ian> thrust of your arguments, in this thread.  Your messages feel
    Ian> very hostile to 

I'd like to try and step in.

Ian, it sounds like you're frustrated.
I'd like to understand exactly why.

Is it that  you're frustrated  because you've spent a lot of time
working on documenting what you think is the simplest, best option, and
others are disagreeing?

I do find the work you've done valuable.  But like Ansgar I find that it
demonstrates there is a lot of complexity in the dgit work flows.  I
don't think this is a criticism of your work; I think that the reason
people are pointing to your work is that it clearly demonstrates the
complexity.

I also know that it's easy to sweep the complexity that we're familiar
with under the rug.  I hear your concern that people advocating other
approaches may be hiding complexity and that we need to be careful not
to hide complexity simply because it is undocumented.


That said, I think Ansgar has some really valid points.  I think that
dgit (or git-dpm) are the hardest work flows to teach.
One of my coworkers in a debian developer.
I could teach him dgit (although I think he already knows it
reasonably).

I would not expect to succeed at teaching dgit or debrebase to the other
two engineers at my company, although I'm kind of tempted to try as a
discussion point.

I was going to argue that I thought teaching gbp pq was easier than
dgit, and that's true up until you have to update a patch.

I do think I could teach the other engineers separate debian repository.
That's certainly true assuming that upstream doesn't need to be changed.
I think that so long as I said redo your patches from scratch every new
upstream release I could even teach separate debian repositories.

By teach dgit I mean teach dgit well enough to add an upstream patch,
and migrate that across to upstream releases as they change.

I think that patches applied git workflows have a lot to add.  I know I
don't want separate debian repositories as my preferred workflow.  But I
do think there really is a lot of complexity here, and I think that it
is a lot easier to get someone started with some of the simpler
workflows.

That said, I also hear your argument that for downstreams who are
want to just add a patch or two (and throw it all away and start over
when they take a new upstream), patches applied workflows are easier.