[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git-buildpackage pattern question



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.  If upstream has tarball releases,
when moving from 1.0.2, you would advance the upstream branch to 1.1.1
with:

    gbp import-orig --upstream-vcs-tag=1.1.1 /path/to/tarball

and gbp will make a merge commit in the upstream/latest branch that moves
all files to the contents of the 1.1.1 tarball, forcing all files to move
to the 1.1.1 contents.  You will then, from Git's perspective, have a
commit in the upstream branch that goes from 1.0.2 -> 1.1.1, and you can
merge the upstream/latest branch into the debian/sid branch without any
conflicts.

If upstream doesn't do tarball releases, you can't use gbp import-orig (I
think), so you have to synthesize that commit yourself.  You still need a
separate branch that doesn't have your packaging files.  Conventionally,
this is upstream/latest.  This gets a bit tricky, since you have to use
the "ours" merge strategy.

I *think* something like this would work, but I haven't tested it.

    git checkout -b upstream/1.1 1.1.1    # assuming 1.1.1 is the upstream tag
    git merge -s ours upstream/latest
    git branch -d upstream/latest
    git branch -m upstream/1.1 upstream/latest

The idea is that you want to move the tip of upstream/latest to a commit
that exactly matches upstream's 1.1.1 release, but which Git has recorded
as a merge between upstream's 1.1.1 branch and your existing
upstream/latest branch (which was upstream's 1.0.2 branch).  This will
give Git enough information to properly merge your new upstream/latest
branch into your debian/sid branch by just moving upstream source to 1.1.1
without changing anything about your packaging.

I think gbp import-orig, under the hood, does something more complicated
using Git plumbing to create the merge commit directly.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: