Guido Günther <[email protected]> writes:
> Could you describe the branch layout you use and "user interface" you'd
> expect from git-import-orig for that?
The branch layout is identical to the "normal" git-buildpackage layout: a
master branch, an upstream branch, and a pristine-tar branch. The only
real difference is that the import of the tarball is committed as a merge
against the upstream tag.
The core of the script in openafs for doing this is:
# Unpack the tarball.
dir=$(basename $(tar tzf "$tarball" | head -1))
tar xzf "$tarball"
# Add the tarball to the current index and then use that to create a tree
# object corresponding to the contents of that directory. Then, use
# commit-tree to commit that to the repository.
git add -f "$dir"
tree=$(git write-tree --prefix="$dir"/)
commit=$(echo "Imported upstream tag $upstream via tarball" | \
git commit-tree "$tree" -p upstream -p $(git rev-list -n1 "$upstream"))
# Now that we have a commit, repoint upstream at that commit, tag it, and then
# remove the unpacked upstream tarball from our index.
git branch -f upstream "$commit"
git tag "$tag" "$commit"
git rm -q -r -f "$dir"
rm -rf "$dir"
much of which I suspect is the same as the normal git-import-orig process.
> I assume you'd have something like:
> git-import-orig --upstream-vcs-tag=v1.0.0 upstream_1.0.0.orig.tar.gz
Yup, that looks right.
> Which would create something like:
> + master
> |\
> | \
> | + upstream, upstream/1.0.0 contains upstream_1.0.0.tar.gz
> | |\
> | | \
> | | + v1.0.0 (on upstream's git branch)
> | | |
> | | |
> ...
> Where 'master' is the branch with the debian packaging, 'upstream'
> git-buildpackage's upstream branch. and v1.0.0 a tag on where the "real
> upstream development happens" (from upstream's git).
Yup!
> Is that correct? If so I could try to get around to add that. It seems
> the only modification needed is to specify an additional parent when
> importing the upstream tarball or am I missing something?
No, I think that's the only real change. It should be fairly simple for
someone who knows the right place to add the change.
I vaguely remember that you want the upstream tag to be the second parent
for some reason, although I'm not sure about that. It's probably worth
poking just a little at whether it should be the first parent or the
second, although openafs has always made it the second parent and that
seems to work fine.
This of course doesn't answer the workflow question if upstream only
produces tags and not tarball releases, but I think that case is actually
somewhat simpler apart from figuring out how to generate a tarball to use
as the basis for the Debian packaging (and I think git-buildpackage
already has mechanisms for generating a tarball from the upstream branch
and storing it so that it's reproducible, so that's probably the right way
to go for such packages).
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
