A (git) workflow for Debian packaging

[Pierre Habouzit]

FWIW I use a very simpler workflow, using rebase, because rebase does
not always sucks ;)

I have an "upstream" branch, that is either the upstream git when I'm
lucky enough, or any kind of upstream into git thing (through git-svn,
imported tarballs, whatever).

I also have a "debian" branch that is the one that get tagged along
the way. If needed I may rater use debian/$release if needed, to deal
with stable updates.

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). And I do rebase that
branch if needed. You can scale that to as many patches branches you
need if you have more patches, and that you want to sort them by topics,
you will understand how it works easily.

let's take an history:


  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.
The important part is to never ever _merge_ anything _in_ "patches".
"patches" should never ever touch debian/ (except to remove it if
upstream has one).

  When I intend to package a new upstream (Ver1) or even an intermediate
snapshot, it does not matter, I go in the "patches" branch, and I:

  % git rebase --onto Ver1 Ver0 patches

Yes, rebase. Rebase will rewrite the "patches" branch, not erase what
is already merged into "debian" !!!  This way, the branch ]Ver0 ..
patches] is rewritten onto Ver1. If patches have been integrated
upstream as is, rebase will notice it and skip the commits (e.g
cherry-picks will do that), or if upstream integrated a slightly
different one, you'll get conflicts to resolve (that's life).

  It's a good idea to review (e.g. in gitk) the new state of "patches"
to check if you wouldn't want to refactor some patches, if you need to:

  % git rebase -i Ver1 # edit, squash, reorder at your own liking

  Then I just merge this new "patches" branch into "debian" again, and
history looks like:


  Ver0        ...            Ver1
---O---o---o--...-o---o---o---O---o---o---o---o---> (upstream)
   |                          |
   \                          \
    p---p---p-...--p           p---p---p (patches)
            | ...   \___               |
             \...       \               \
--x---x---x---...x---x---X---x---x---x---x---X---> (debian)
                       Ver0-3               Ver1-1

  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".

  The good point, is that if upstream know that your patches branch gets
rebased all the time, then all is fine. Upstream just has to look at
"patches" to grab the patches he doesn't have yet, and _you_ as a
maintainer can know what was in the "patches" branch, when you were in
version "Ver0-3" because when you merge "patches" you'll get:
       "merged branch patches into debian"
commits. You just have to use gitk (or probably some git rev-list magic
will do) to trace the thread that comes from "Ver0" and merges into
"Ver0-3" and you're done.

  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.


Note that unlike what it seems, it works even if there is many
maintainers. In that model, a central repository is needed, and is used
as a synchrnization point. It's important that "patches" (or every topic
patches branch if many) have a linear history (else it makes the rebase
onto a new upstream quite harder).

-- 
·O·  Pierre Habouzit
··O                                                madcoder at debian.org
OOO                                                http://www.madism.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071005/8f0254ce/attachment.pgp