A (git) workflow for Debian packaging

[Pierre Habouzit]

On Sun, Oct 14, 2007 at 03:49:15PM +0000, martin f krafft wrote:
> 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 ;)
> [...]
> > 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.
> 
> I am experimenting with this workflow for my upstream-patches branch
> now, and I am begining to start to like the concept. However,
> I still have a few issues.
> 
> >   % git rebase --onto Ver1 Ver0 patches
> 
> After this, you need to use 'git push -f patches' to update any
> remote, such as git.debian.org. This in and of itself it kind of
> ugly, but what's worse is that you have to disable
> receive.denyNonFastForwards on the remote end, for *all* branches.
> Do you simply not mind? Wouldn't this open up the repo for some
> problems if you're working with others?
> 
> I wish Git had the concept of such cherry-pick branches: I could
> configure upstream-patches on the remote such that it can receive
> non-fast-forwards without the need for git-push -f...

  Yes of course, to publish a rebased branch you have to git-push -f.
  I never set denyNonFastForwards so I'm not worried. And yes, maybe git
should have a flag to tell "yeah, don't make me spell out push -f for
this this and this branch, because I rebase them on purpose".

  Oh and btw, the rebase may be an issue while working with many people.
It happens only when you package a new upstream version (or a new
snapshot), so it's not often, but when you do, you have to warn the
other people you work with that you will do the rebase and push -f.
because you could end up "loosing" commits they have pushed between the
moment where you fetched last time, and the push -f you will do. It's
not very pretty, but as said, it happens seldomly (new upstreams, and if
your topics branches are not empty of course).

  Right now, I work alone so it's not an issue. The other way to do that
is to have a coordinator in the team that is responsible for fetching
things from the others members repositories, merge and push to the
central one. Though it could become a SPOF.

-- 
·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/20071014/b1da757c/attachment.pgp