-----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.
- --
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:j...@jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTUv2EJlgi5GaxT1NAQIrAQP/ZQAVu+AxIC5TGiU8MP6XfXihyNdA+qwL
vmmSRLXb8jifAKtbbyk9z8Ucn6rzQW5vbeNJStvt4hpPDM224CwMDgUu2XFBums+
j8e7SEUvXmNleiwmwUsDAEqFYWRw3/rUmZIUvt/FWhy1lhrgOyIwFObeDMxjYdSG
1JFJrM5DHUo=
=yB4X
-----END PGP SIGNATURE-----
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
