On Tue, Aug 05, 2014 at 03:31:03PM +0200, Martin Pitt wrote:
> If you maintain a package which already is in git in Debian, I warmly
> recommend that instead, as locally maintained git branches/patches
> tend to get lost or outdated.
Absolutely. If everything is already in git and logically separated,
then it's already in a state that's easy to work with, so this is the
preferable way to do it.
In this case, git-dch can probably replace my
git-reconstruct-changelogs, and my git-commit-dsc becomes unnecessary.
The gbp workflow handles the .git directory internally, so xgit isn't
useful there either. git-merge-changelogs might still be useful, though.
I think I'd prefer continue to rebase Ubuntu onto Debian, rather than
merge from Debian, which I've seen done sometimes. What I want to keep
track of is the delta from Debian as it stands today, over how I got
there. When I see a merge from a Debian branch into an Ubuntu branch, I
lose that visibility. I can still ask git for a diff, but I can't
rationalise that into logical commits easily.
My need was to have a fallback that covers every package (including
apache2, for example which is a UDD failure). I think most of the
tooling and workflow I'm describing is to "catch up" to the state that
you are in with systemd, for packages that are not maintained in git
(whether in Debian, Ubuntu or both). Then the workflows converge.
One thing I've tried to do is to separate debian/changelog changes into
a separate commit (eg. at upload time), instead of adding to them
incrementally. AIUI, gbp supports this too, with git-dch, but not
everybody does it this way. This causes (a small amount of) pain when
cherry-picking, since there's almost always going to be a merge conflict
in debian/changelog that I don't care about and then have to throw away.