Tracking topic branches with rebases vs. merges (was: Branch dependencies)

From: martin f krafft <madduck@madduck.net>
Date: Aug 3, 2011, 10:10 UTC
Message-ID: <20110803101022.GC27996@fishbowl.rw.madduck.net>
In-Reply-To: <CAKPyHN0EsXMKQ2g7ONaO4yw2ioPbMhg8XCsmB20je=O1DDeE5Q@mail.gmail.com>

also sprach Bert Wesarg <bert.wesarg@googlemail.com> [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@madduck.net