Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman <hartmans@debian.org> writes:
>>>>>> "Ansgar" == Ansgar <ansgar@debian.org> writes:
>
> Ansgar> Sam Hartman <hartmans@debian.org> writes:
> >> I'm having a bit of trouble here and am hoping you can help us
> >> out. Ian asked what git workflow it is that you're talking about
> >> where people can deal with commit push and pull and don't need to
> >> know more.
> >>
> >> I didn't see a clear answer to that. Which debian packaging
> >> workflow do you believe has that property?
>
> Ansgar> There is no need for a vendor branch if only the packaging
> Ansgar> information is kept in the repository, i.e. only debian/.
> Ansgar> In particular there is no need for branches or merges for
> Ansgar> regular updates (i.e. not based on an older release).
>
> 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?
Sure.
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
Note that CVS already had a mechanism for tracking upstream releases
(vendor branches); I'm not sure how widely they were used, but as far as
I understand they were usually seen as advanced use of CVS. Git makes
maintaining such vendor branches easier (better merging), and some
workflows for Debian packaging result in trivial merges, but it is very
confusing when something unexpected happens.
Ansgar
Reply to: