Thomas Heller <thom.heller@googlemail.com> 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 http://www.aragost.com/mercurial/