[Python-Dev] Hg: inter-branch workflow

Thomas Wouters thomas at python.org
Sun Mar 20 18:32:54 CET 2011


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:
> >
> >
> > 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.
>
> Well, YMMV.  But instead of spreading FUD you might want to state *why*.


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.

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.
You can see what's going on with 'hg outgoing -p', but I, as an observer,
have no way of knowing whether you used that and were aware of what exactly
you were pushing.

Merges can also contain useful information about how *future* merges of the
same changes should be handled. This doesn't matter much to changes with
short turnaround (or changes that are continuously reverted and re-applied)
but can make things a lot simpler if you have lots of diverging work in
multiple branches -- and all the getting used to Mercurial aside, I'm sure
that is what we're actually doing it for.

Even when done correctly, in situations where merges are automatic and do
not involve the changed code in any way, I don't like rebasing a single
changeset because it makes it less apparent when the actual work was
started. It's not any worse than diffing and re-applying a changeset, but
for example if your change modified a particular call pattern appearing in
multiples places, and another place started using the same pattern somewhere
in your merges that you made go away, did you intentionally forget to fix
the pattern or was it an accident? This isn't a problem that is *caused* by
rebasing, but it certainly isn't helped by it. 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.
No matter that it *usually* doesn't matter, or even *almost never* matters,
it *can* matter.

Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy
luddite misanthrope) greatly prefer the automatic (and mostly silent) merge
as BitKeeper does it, in the long run the actual merging and the merge
changesets are unavoidable and something to get used to, not dodged around
(at least not at this cost.)
-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110320/f0f1d81e/attachment.html>


More information about the Python-Dev mailing list