[pkg-otr-team] summary of the 'git is better than quilt' talk

[Antoine Beaupré]

On 2014-03-01 11:15:17, micah wrote:
> intrigeri <intrigeri at debian.org> writes:
>
> [lengthy productive discussion snipped]
>
>> I *thought* that pkg-systemd had, but they're in the process of (very
>> likely) moving from git-pkg + single-debian-patch to "standard" gbp,
>> so... anyone wanting to watch DebConf13's (or 12's) panel about Git
>> packaging workflows?
>
> There is this:
>
> low:
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/low/1035_Introduction_to_git-dpm.ogv
>
> high:
> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/1035_Introduction_to_git-dpm.ogv
>
> this talk is titled 'git is the better quilt: Managing Debian packages
> in git with git-dpm'

The talk goes in lengths about the basic workings of git: commits,
trees, rewriting history and all.

Pretty much all stuff people here probably know for the first half, but
a good refresher (which I fast-forwarded).

The talk doesn't adress, in my opinion, the problems that were outlined
with the necessary rebasing that needs to happen if we are to follow
patches upstream. There's a hack that seems to be used that we rebase
anyways, and remerge with the upstream branch.

I think the workflow suggested is something like, for updating our
patches from the upstream 1.0 to 1.1 release:

    git pull upstream # merges upstream changes in the master branch
    git rebase 1.1 patches/foo
    git rebase 1.1 patches/bar
    git checkout patched
    git merge patches/foo
    git merge patches/bar

Notice how one branch per patch is used here. I also have no idea how
those rebased patches branches can be sent upstream. If someone wants to
figure this out, this is around 30 minutes into the talk. More about the
"patched" branch later.

git-dpm is talked about only at 33:43. So the talk is basically 12
minutes, if you want to watch it...

The first thing I noticed is that the "master" branch is reserved for
the debian/ + patches stuff, which is usually something i call the
"debian" branch. The upstream master branch is instead named "upstream",
something I usually leave called "master".

Interestingly enough, there's also a "patched" branch which seems to be
the equivalent of the "patches" branch I suggested originally. It's
basically "upstream + patches but not debian/".

The debian branch (which is called master) merges the upstream and
"patched" code. Only the debian branch is published, the "patched"
branch stays only locally. This is discussed around 37:00.

One thing is cool: git-dpm takes care of a lot of the magic for us. The
above rebasing stuff pretty much happens automatically - or at least
that's the pitch, I haven't tried it out. :)

There's a dpm command to automatically generate the patch set to send to
upstream. If I understand properly, it also maintains the debian/patches
directory.

Then there's all sorts of nift commands to maintain debian/changelog and
so on.

So basically, I think it's an interesting tool, but it's something we
would all need to jump into, otherwise it's just too complicated to
manage - this is basically my "patches" idea, but actually with a bunch
of helpers to make it tolerable.

*and* it still stores patches in debian/patches.

So I'm not sure this is the right way to go. Definitely not the
consensus, I would say, but a cool new idea.

Maybe if someone would actually try it and report we might have a better
idea.

A.

-- 
I worry about my child and the Internet all the time, even though
she's too young to have logged on yet. Here's what I worry about. I
worry that 10 or 15 years from now, she will come to me and say
'Daddy, where were you when they took freedom of the press away from
the Internet?'           - Mike Godwin, Electronic Frontier Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-otr-team/attachments/20140302/f6425c5e/attachment.sig>