A (git) workflow for Debian packaging
martin f krafft
madduck at madduck.net
Sun Oct 14 15:49:15 UTC 2007
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...
martin | http://madduck.net/ | http://two.sentenc.es/
"the duration of passion is proportionate
with the original resistance of the woman."
-- honoré de balzac
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071014/2ff08aca/attachment.pgp
More information about the vcs-pkg-discuss