A (git) workflow for Debian packaging

[martin f krafft]

also sprach Pierre Habouzit <madcoder at debian.org> [2007.10.05.1620 +0100]:
> FWIW I use a very simpler workflow, using rebase, because rebase
> does not always sucks ;)

No, and I did not mean to suggest that it does, but it is very
confusing to some people.

> Then there is two cases. Either I have few patches to add to the
> software, and that's often the case, and I have a third pseudo
> branch, called patches, where I put the patches (YA'RLY).

What do you mean with pseudo branch?

>   Ver0                                   Ver1
> ---O---o---o---o---o---o---o---o---o---o---O---o---o---> (upstream)
>    |
>    \
>     p---p---p---p---p---p---p---p (patches)
>             |               |    \___
>              \               \       \
> --x---x---x---x---x---x---x---x---x---X---x---x---x---> (debian)
>                                    Ver0-3
> 
> patches can be built with as many cherry-picks from upstream as
> needed.

You mean you might cherry-pick a commit from upstream after Ver0 was
released and track it in your patches branch?

> "patches" should never ever touch debian/ (except to remove it if
> upstream has one).

Right, so your patches is my upstream-patches: patches which apply
to upstream without depending on or assuming the existence of
Debian.

> The important part is to never ever _merge_ anything _in_ "patches".

Why is that important?

>   If upstream wants to take your contributions, then it can do whatever
> he wants with patches in your patches branch, even merge it if he wants
> to take everything. He should just never branch if off.  FWIW it works a
> bit like Junio in git uses "pu".

Right, and why would upstream ever want to branch off my patches
branch. Cherry-picking makes *much* more sense there. Thus, it
doesn't matter that you are publishing a rebased branch because Git
is smart enough to detect

(a) if upstream cherry-picks a commit again, even though it has
a different commit ID after the branch was rebased.

(b) if you merge upstream's new version, which includes patches
cherry-picked from you.

>   Like said, this approach works very well even with many patches-like
> branches. Keeping them under a common namespace can help people
> understand they should only merge them or cherry-pick from them, and
> never branch them off.

What is a good namespace to use for that?



Thanks for sharing your workflow with us. One thing I don't see is
how you separate different aspects of the Debianisation, or do you
just not care? Or is that another one of the "patches" branches,
just not designed for upstream since it may well touch ./debian/?

And another thing that I notice is that your and my workflow are
actually rather compatible: if I rebased my upstream-patches branch,
which I might do after reading your stuff, we'd have more or less
the same flow, except that I also use multiple branches for
Debian-related changes, which I would *not* rebase, but merge
still...

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
 
oxymoron: micro$oft works
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071005/a5a77b04/attachment.pgp