Re: Playing with git-buildpackage
Hi,
On Thu, 21 Aug 2014, Barry Warsaw wrote:
> Then I `git init`'d a new local repository and used `gbp import-dsc` to
> initialize the git information. That seemed to work just fine.
FWIW, I usually setup the repository on git.debian.org first and then I
clone that empty repository. With this process, the git repository already
has the "origin" remote already setup.
> Now I wanted to update the package to 2.0.1, so I used `git-import-orig
> --uscan` which works great, except that it doesn't add a debian/changelog
> entry. That would be a nice convenience I think.
gbp's developer is relatively active, feel free to file wishlist bug
reports for that kind of things.
> `gbp pq` is the tool to manage the patch branch, but there were a few things
> that seemed messier than with the git-dpm experiment:
>
> * I used `gbp pq switch` to get to the patch-queue/master branch. Unlike with
> git-dpm, this does *not* delete the debian/ directory. It did make things
> smoother with Emacs because upon switching back (later) to master, I didn't
> have to revert the files I was visiting. But I realized that it did leave
> me in a somewhat confusing state. Should I use quilt? The patches were not
> automatically applied by `gbp pq switch`. Maybe I should have imported
> them.
"gbp pq import" is the right command indeed, it will create the branch with
everything required and switch to it.
> It makes me think that git-dpm's handling of debian/ is probably closer to
> right, so that there'll be no temptation to muck about with quilt while in the
> patches branch. Maybe a better approach would be to delete just
> debian/patches - that would remove my confusion but wouldn't force me to
> revert all the debian/ files I was editing.
When you analyzed git-dpm, the lack of debian was a negative point, so it
would be weird to want to remove it here.
What you possibly need is an enhanced shell prompt displaying the name of
the current branch, it's relatively easy to do by embedding $(__git_ps1
2>/dev/null) somewhere in your $PS1. That way you immediately see that you
are on the patch-queue branch...
> I was disappointed with the documentation surrounding the `gbp pq` workflow.
> It's not really described in the git-buildpackage manpage and the best
> documentation for `gbp pq` is off-site and external to debian.org.
man gbp-pq ?
It effectively points to the website of the author, but that doesn't sound
like a problem. It's possibly because the software is quite well
documented on https://honk.sigxcpu.org/piki/projects/git-buildpackage/
that there's no wiki page or anything like that explains everything.
> The other disappointing thing is that once I was back on the master branch,
> the patch-queue/master branch was not deleted. That's a nice little cleanup
> that git-dpm handles for you. After all, who wants that temporary patch
> branch on git.d.o?
Why would you push your temporary branch?
I know this can happen if you do "git push --all" but that command is
not a good idea in general... you can do "git push origin :" to push all
the branches that are pre-existing on the remote side.
Keeping the branch makes it easier to rebase it in the future and then
re-export the patches.
> git-buildpackage has --git-ignore-new but that's actually not enough! Because
> of the vagaries of git, you have an extra "level" of changes, i.e. the index.
> This means that if you want to include uncommitted changes in the package, you
> need to also use --git-export. There are two options here: --git-export=INDEX
> obviously includes the staged changes while --git-export=WC includes the
> working copy. =WC seems much more aligned with my own personal preferences,
> and is closer to what svn-bp does by default.
Note that this is only required because you actually use
--git-export-dir=../build-area/. When you don't do that you build out of
the working copy and --git-ignore-new is then enough.
> Once I uploaded the package, I had trouble with git-bp --git-tag-only
> recognizing my gpg keys. I didn't investigate further, but just used
> --git-no-sign-tags for now.
I never had any problem with signing the tags. Does your git identity
matches your identity on the GPG key?
> After this experiment, my own personal preference is leaning toward git-dpm.
> It just seems like a cleaner, more self-contained, and better documented
> workflow. I think there's room for improvement, but git-dpm is "just" a fancy
> shell script so I hope it's maintainer will be open to patches and
> suggestions.
gbp is Python and the author is also open to patches and suggestions :-)
> In truth though, I bet it won't be hard to convert from one to the other. The
> biggest difference that I can tell is that if you use the default branch
> names, it's mostly just the tag names that differ:
>
> git-dpm: {debian,patched,upstream)-<version>
> git-bp: {debian/upstream}/<version>
In python-django, I just switched to debian/<codename> +
upstream/<upstream-branch> following early results of the current
discussion about git repository layout on debian-devel.
> Two other things: the hooks that get installed in git.d.o end up sending
> emails to the python-modules-commit mailing list. Unfortunately, all my
> changes get held for moderator approval. I emailed the list owner and have
> not heard anything yet. Does anybody here have admin privs for that mailing
> list? I don't have the same annoyance with svn-bp.
It would be nice if the admins could whitelist all mails containing
an "X-Git-Repo" header.
Or at least whitelist all *@users.alioth.debian.org emails as those are in
the From of those emails. (I just changed a setting so that it uses this
domain now)
Alternatively you can subscribe to the list with your
<login>@users.alioth.debian.org mail and disable mail delivery for that
address.
> We should probably also connect the commit hooks up to IRC as is the case with
> svn-bp. I don't know about you, but I definitely do not want more email
> traffic. Notifications in IRC are fine, more email is not! :)
I did just setup the IRC notifications and also enabled
/usr/local/bin/git-post-receive-tag-pending that will tag the closed bugs
as pending.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: