Hello, On Sun, Mar 20, 2016 at 04:35:27PM -0700, Russ Allbery wrote: > Ross Vandegrift <ross@kallisti.us> writes: > > > In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2. > > So my packaging looks like this: > > > o---o--------o--------o--------o------------o master > > \ \ > > o---o 1.0.0 o---o 1.1.0 > > \ \ > > o---o 1.0.1 o---o 1.1.1 > > \ > > o---o 1.0.2 > > \ > > o debian/sid > > > To update to 1.1.1, I've read that I should merge 1.1.1 into debian/sid. > > But this is painful - upstream 1.1.1 conflicts with 1.0.2. > > This is exactly why git-buildpackage by default uses an upstream/latest > branch that tracks upstream releases. [...] In my usage of git-buildpackage, I've been using a different approach to that suggested by Russ and I thought it might be useful to share it in this thread. I think of (local) branches as things that I expect to make commits to, and use tags to keep track of work done by upstream that is read-only from my point of view. So in my repository I have all of upstreams tags (1.0.0, 1.1.0, 1.0.2 etc.) and a master branch which contains both upstream's code and my debian/ directory. There is no upstream branch. When there's a new release, I fetch upstraem's tags and then run something like `git merge 1.1.1 && dch -v1.1.1`. In the case you describe where 1.1.1 cannot be cleanly merged with 1.0.2, I would just run `git merge --strategy recursive --strategy-option theirs 1.1.1 && dch -v1.1.1` which is similar to what Russ suggests, though it avoids overwriting anything in debian/. This will always work because all my modifications are quilt patches so it's okay to overwrite anything outside of debian/ with the newer upstream version. The advantage of this is that you don't need to worry about maintaining an upstream branch. You just merge tags into your packaging branch, using the merge strategy to make sure the merges succeed as necessary. And you don't need to go anywhere near upstream tarballs (you can generate some using gbp's integration with pristine-tar -- these are just as good as e.g. the tarballs generated by GitHub). -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature