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.
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
