[python-committers] Create a Mercurial repository with a branch per issue

[Tarek Ziadé]

On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea <jcea at 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
>    \
>     \-->5
>
> Two 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