On 1/7/2012 3:57 PM, Remy Blank wrote:
> Christian Boos wrote:
>> These branches are best kept linear, for easier integration
>> upstream. If after a while, the changes don't apply anymore
>> on latest code from upstream, then you should rather rebase
>> the changes instead of merging with upstream, as it's more
>> difficult to examine and reintegrate a branch if it contains
>> merge changesets.
>
> I still don't understand why people keep wanting to rebase instead of
> merge. I have been working with Mercurial for years now, and I still
> haven't had a valid use case for rebasing. The same applies to MQ, for
> that matter.
Well, I had to deal once with such a sequence of original commits
interspersed with merges with upstream and tried to 1)
distinguish inside the merge commits the conflict
resolution (interesting) from the changes brought from
upstream (uninteresting), 2) try to reintegrate some of the
changes back upstream. Neither task was easy with merges, but
would have been with a rebased branch (or a refreshed MQ stack).
Of course, if you simply want to merge the topic branch back in
upstream, then you perhaps don't need to do these intermediate
steps and the only disadvantage would be some extra noise in the
graph, a minor inconvenience.
But it's not what we need to do here. First, we don't have a
DVCS, so in Subversion the only choice left for reintegrating is
between integrating all the changes from the topic branch at once
as a single collapsed changeset, or committing again the
individual changesets from the topic branch one by one. In the
latter case, you'd have to "reverse engineer" the rebase from the
original changesets plus the merge changesets. This is quite
painful, but you have no other choice when you don't want to take
all the changesets of the branch. And even if you'd take all of
them, it's just a nicer thing to do, to reapply the changes with
their original commit log one by one, as smaller changesets are
better for explaining the changes and isolating a regression.
Even if we used a DVCS, the revision graph just looks nicer and
easier to understand if each merged topic branch is itself a
linear one and doesn't contain other merges.
Example:
-- 1 -- 2 -- 3 -- 4 (upstream)
\
-- a -- b -- c (topic)
Simple.
A few merge and modifications later:
-- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
\ \ | \
-- a -- b -- c -- d -- e -- f -- g (topic)
Now you have to find out that that (d) is merge that besides all
the changes from 2, 3, 4 also contains changes which resolved
conflicts between 2 and b, 3 and c... That (e) brought all the
changes from 5 and 6 and nothing more, that (g) again solved a
conflict between 7 and b...
How would you now reintegrate back such a branch on top of
upstream, as a -- b'' -- c' -- f? Frankly, I think you wouldn't
and instead you would just apply diff(7, g) and be done with it,
no?
I much prefer a workflow where it's easy to reintegrate the topic
branch as a sequence of changes.
With a DVCS, if you had done a rebase rather than a merge at the
same reference points as in the above (4, 6 and 7), you'd get the
following graph:
-- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
\ \ \ \
\ \ \ -- a -- b'' -- c' -- f (topic.4)
\ \ \
\ \ -- a -- b' -- c' (topic.3)
\ \
\ -- a -- b' -- c' (topic.2)
\
-- a -- b -- c (topic)
And the final merge would look like:
-- ... -- 5 -- 6 -- 7 ---------------------- 8 (upstream)
\ /
-- a -- b'' -- c' -- f (topic.4)
Note that the intermediate branches topic, topic.2 and topic.3
would still be present in the contributor's repository, but
wouldn't be pushed in the upstream repository.
And finally in Subversion, that would just appear as:
-- ... -- 7 -- a -- b'' -- c' -- f (upstream)
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
