Hi, 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. 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. Or maybe I didn't understand correctly how --upstream-vcs-tag is supposed to work ? Thanks in advance for your answers ! Regards, -- Raphaël Halimi
Attachment:
signature.asc
Description: OpenPGP digital signature