On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/02/11 13:15, Victor Stinner wrote:
Rebasing is good before committing to the "real" repository, but anybody with a checkout clone will suffer.
Why?
Rebasing alters history. It messes with the "inmmutable" nature of history. Anybody with a clone must do it. If you don't do, when you resync, you will see a new head and your clone will be "different" of the one doing the rebase.
That is, suppose:
- -->1-->2-->3-->4
Now you rebase and collapse changesets 2-4, to get ready for merging with the real respository. You have:
- -->1-->5
in your repository.
Anybody that had cloned from you, when pull, will have in her repository:
- -->1-->2-->3-->4
\-->5Two heads, "different" repository views. If this second person has a patch in his own repository, and you try to merge back, you will get again the original changeset list, two heads, etc.
As a general rule, rebase should be done ONLY in personal clones not shared by anybody. Or, in this particular case, a clone should be automatically destroyed after merging to main development line.
That's why I think it's much cleaner to work with mq to build a clean single-commit patch, even if a clone may be used for temporary states and sharing.
We are experiencing merge hell right now in Distutils2, as the contributor list grows, because of the way people work with clones. We are polluting history with a lot of "merge" commits because it's the most simple way to work w/ mercurial.
I don't want to fork this thread but I think we should set up a "mercurial good practice" guide somewhere for hg.python.org could be awesome, in particular since the number of indirect contributors is going to grow with Python under a DVCS
Cheers Tarek
-- Tarek Ziadé | http://ziade.org