also sprach Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> [2011.08.03.0125 +0200]:
> I think that having the TopGit philosophy of one feature branch is
> one patch, you can handle an rebased upstream. Thinking of
> a feature branch as a series of patches makes this way harder. But
> I would like to have this philosophy.
Let me just make sure I understand you right: you do not like the
following branch management strategy:
o--o--o--+--o--o--+--o-.
/ / / \
o--o--o--o--o--o--o--o--o--o--o--●
and you would prefer if the topic branch was rebased all along (like
what git.git advocates), and then transferred to mainline with
git-format-patch/git-send-e-mail/git-am (or ff-merged).
I am torn on this issue. On the one hand, I do not find the above to
be so problematic, especially not if the downstream merges happen
only infrequently (undo merges that do not produce conflicts, as
advocated by gitworkflows(7)).
On the other hand, I completely agree with you that rebasing is much
nicer, and it certainly works without publishing the branch. In
git.git, people seem to maintain their own branches and send patch
sets to the mailing list for review.
But how could you and I truly cooperate on a feature branch without
using merges, and without establishing a lock-unlock protocol to
ensure only sequential updates of the refs?
Thanks,
--
martin | http://madduck.net/ | http://two.sentenc.es/
"alles gackert, aber wer will noch still
auf dem nest sitzen und eier zu brüten?"
-- friedrich wilhelm nietzsche
spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)