Boost logo

Boost :

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-21 09:37:51

Thomas Heller <thom.heller_at_[hidden]> writes:

> On 03/21/2012 01:35 PM, Oliver Kullmann wrote:
>> And this will only happen very rarely: Exactly since people have
>> *local* repositories, they can handle their *local* repositories:
>> First keep everything, every little silly mistake (you never know),
>> and once its finished, they clone this local repository, the clone is
>> carefully prepared for publication and review, and this is then
>> pushed to the main repository.
>> In the above example, we have the case where a "local repository" is
>> also a "public repository". This should then be flagged as such, and
>> thus everybody will understand the rewriting of history (since it is
>> the purpose of the local repository to get integrated into the main
>> repository). One could also handle this via branching --- the version
>> with the changed history becomes a new branch.
>> So one needs some policies about that, but that's natural.
> I'm sorry, you totally lost me ... So on the one hand, git is the tool
> to use in order to better collaborate, but on the other hand it is
> totally unusable when you actually want to collaborate?

Collaborate means pulling commits from another repo, creating some more
commits and pushing them back. Commits are meant to be immutable in both
Git and Mercurial and you collaborate by adding more changesets to the
ever-growing public history.

Both tools give you the option of changing your local commits. So you
can create changesets x-z:

 ... a --- b --- x --- y --- z

You then change your mind and want to fix a typo in y. So you edit y and
when you are done you have created y' which is simily to y (but not
exactly the same because of your change). You also end up with a
different z since the history of z has changed:

 ... a --- b --- x --- y' --- z'

Now, if someone else has already pulled x-y from you, he will still have

 ... a --- b --- x --- y --- z

in his repository. If he pulls *again*, then he ends up with:

 ... a --- b --- x --- y --- z
                   y' --- z'

The similarity between y and y' and between z and z' is not recognized
by either tool so he gets a kind of doppelgänger changesets.

This is not really dangerous, but it's a mess and it defeats the
purpose: you tried to edit y since you wanted to publish a better
version of y. You now ended up publishing both the old y and a new y and
made the history more messy as a result.

The rule is that you should not modify changesets that have "escaped"
into other repositories. Mercurial 2.1 will track if a changeset has
been published or not and commands that modify history (such as rebase)
can take this into account and abort if you're modifying public changes.

Martin Geisler
aragost Trifork
Professional Mercurial support

Boost list run by bdawes at, gregod at, cpdaniel at, john at