Hello,
On Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi wrote:
> I'm not sure if this question belongs to -mentors or -devel, so I'll
> post it here at first, feel free to relocate/cc if you think it's
> appropriate.
-mentors is fine.
> I'm trying to fully understand the git-buildpackage workflow and I'm
> kind of stuck on a specific part of the process, regarding the
> handling of the upstream branch when upstream uses git but the
> maintainer still wants to use pristine-tar to commit upstream
> tarballs.
>
> If I understand [1] and [2] correctly, one would need two upstream
> branches : one originating from upstream, with the full commit history,
> and one managed by gbp import-orig, which would contain upstream sources
> imported as single tarballs commits.
>
> [1] http://www.eyrie.org/~eagle/notes/debian/git.html#combine
> [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
>
> I don't understand the reason for having two separate upstream branches.
> Is there a specific reason against having a single upstream branch,
> which would contain the full upstream commit history, and maintaining
> the pristine-tar branch with a plain old "pristine-tar commit <tarball>
> <upstream branch>" (since gbp import-orig would want to import the
> tarball files and create a new tag, which both may conflict with the
> upstream branch/tags) ?
>
> Would it make sense to file a wishlist bug report against
> git-buildpackage to ask for a new option to gbp import-orig, which would
> manage the pristine-tar branch without importing anything in the
> upstream branch, and without creating a second upstream tag ? The
> advantage over plain old "pristine-tar <tarball> <upstream branch>"
> would be to rely on gbp.conf for the upstream branch name instead of
> specifying it every time, and automatic tarball download with the
> --uscan option, whereas plain old pristine-tar needs running uscan
> manually beforehand to download the tarball.
I believe that your analysis is correct. gbp's import-dsc and tarball
management functionality requires an upstream branch and tags on it.
But you could configure gbp to keep these separate from the main devel
branch. If we assume that the upstream repository has a branch called
'master' with tags of the form '1.2.3' on it, you could put something
like this in debian/gbp.conf:
[DEFAULT]
upstream-branch = gbp-upstream
debian-branch = debian
upstream-tag = gbp-upstream/%(version)s
debian-tag = debian/%(version)s
sign-tags = True
pristine-tar = True
pristine-tar-commit = True
Then gbp will do its work on the branch gbp-upstream and it will make
tags gbp-upstream/1.2.3 which won't interfere with your upstream devel branch.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature