On Tue, Mar 20, 2012 at 01:28:34PM -0700, Russ Allbery wrote: > Guido Günther <a...@sigxcpu.org> 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've pushed a version that should do the above. I'd be happy to hear if this looks as expected. What I'm missing from the above workflow is how you actually get started. By creating an empty upstream branch and importing the tarball on top of it? > 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). Yes. The later case just needs a matching upstream-tag pattern and the usage of --pristine-tar-commit. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
