[haiku-commits] Re: AW: Re: haiku: hrev49807 - in src: servers/app servers/app/drawing/Painter servers/app/drawing/Painter/bitmap_painter servers/app/drawing tests/servers/app/unit_tests

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 11 Nov 2015 12:23:11 +0100

Hi Julian,

On 11/11/2015 11:44 AM, Harnath, Julian Axel wrote:

Merge branch 'app_server'
We prefer rebasing instead of merging for a cleaner history.
Even for long-living feature branches? The problem is, when the
(github-)branch lives long enough, you have to merg haiku master into
it every now and then so you won't get too many conflicts all at once
when finished (or maybe the branch work wants to use a feature that
was added in master in the meantime). Of course one could also rebase
the branch onto haiku master, but that'd require a forced push. If
there's only one person working on the branch, that's somewhat ok,
but if there is ever more than one developer working on it, that gets
nasty. So rebasing the feature branch during its development does not
seem to be a good policy. Now another option (the one you mean I
think) would be to rebase the feature branch once at the end, when
it's finished and not used anymore. But then, during rebase, all the
conflicts reemerge which were already solved during the incremental
merges of master into the feature branch, during development. To
prevent having to deal with possible old conflicts, merging seemed to
be the best choice to me.... any ideas?

With the IMAP work (which was at least very long lived), I rebased from time to time, and, before merging, created (locally) an extra branch to perform the final rebase in (that was more complex, as I didn't do that for a year or so).

All in all, I don't think using rebase (and a forced push) is much of an issue, even when working on a branch with several people. You get warned when you update, and fixing your local commits is usually also just a rebase away. It's basically the same work flow if you'd always merge, just with a rebase.

The one thing I really like when merging feature branches is that you know exactly which commit was before the merge, and which one was after. But if that would be something we like to have, we could still rebase, and then force a merge instead of fast forward.

Bye,
Axel.

Other related posts:

  1. Home
  2. haiku-commits
  3. Archive
  4. 11-2015