[Python-Dev] Hg: inter-branch workflow

[Stephen J. Turnbull]

Thomas Wouters writes:
 > On Sun, Mar 20, 2011 at 17:59, Georg Brandl <g.brandl at gmx.net> wrote:
 > > On 20.03.2011 16:50, Thomas Wouters wrote:
 > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.brandl at gmx.net
 > > > <mailto:g.brandl at gmx.net>> wrote:
 > > >
 > > >     The reason why rebasing is not universally applied is that the
 > > >     rebased changesets are different from the original ones (therefore
 > > >     I wrote A' and B') -- even if the diff is the same, the parents
 > > >     are not, and therefore the changeset id (hash) changes.  This is
 > > >     called "changing history", and frowned upon by purists.  In reality
 > > >     it works fine if you know the limits: rebasing really only should be
 > > >     applied if the changesets are not already known somewhere else,
 > > >     only in the local repo you're working with.

This is not complete list.  The other important limit (pointed out by
Nick and Thomas) is that it creates changesets that have not yet been
tested, and therefore need to be tested or collapsed (if you want
bisect searches to work properly).

 > > > It's frowned upon by more than just purists, and it works "in
 > > > reality" as fine as handing out your creditcard and personal
 > > > information over the internet; you can't always tell the result
 > > > is bad, and it can be very painful finding out.

That's a problem with any merging, not just with rebasing, though.

 > I could also ask you what makes you think changing history is frowned upon
 > by *just purists*, or why on earth anyone would think it's a good idea
 > regardless of how practical or theoretical they are.

In practice, people who rebase often rebase the same branch to
mainline frequently.  If so, they detect most conflicts with mainline
as they occur, and this is often more useful context than knowing only
that "this branch was developed in a different context from the
current mainline tip", which is the "purist" reason most frequently
given for disliking rebasing.

That is, in practice people often resolve merge conflicts statically,
just by looking at the diff3 output.  If a developer is rebasing
frequently, on the other hand, they are probably also more aware of
the current context of the mainline, and why the conflicting changes
were made.  This dynamic context may improve the conflict resolutions.

 > As for my dislike, your reason (changing history) and Davids apparent
 > problem seem obvious enough. Aren't they? If you don't rebase correctly,
 > stuff goes wrong. Doing it correctly is harder than people seem to
 > think.

I don't think it is, at least not in theory: just run the test suite
on all rebased changesets.  As argued above, the case for frequent
rebasing is as least as strong as the case for merging a branch
developed entirely in its original context, and only dealing with
conflicts at the very end, quite out of context.

 > Merges can also contain useful information about how *future* merges of the
 > same changes should be handled.

That hg rebasing (and git rebasing, for that matter) doesn't preserve
this information is a design bug (ask any Darcs user :-).  It is
important in practice, of course.

 > Rebasing multiple changesets is worse, because the intermediate
 > changesets are a real lie rather than some fudging of history; your
 > repository was never in that state, that changeset never looked
 > that way and it was never built or tested that way.

Ah, but merging and rebasing are done locally.  The repository *is* in
that state now, and building and testing the relevant changesets can
be done automatically.  (This may be problematic in practice due to
the push race, of course.)  So it's just a matter of project policy to
require those tests before pushing.  People who are bugged by the push
race can do an ordinary merge, and provide less testing thereby.

 > Merging and merge changesets are a fact of DVCSes,

Actually, of any decentralized development.  DVCSes simply provide
tools to make you aware of merges, rather than hiding problems behind
"coalesced" patches that don't even know their parent version.