Since Mercurial's rename is implemented as copy-and-remove, the same propagation of changes happens when you merge after a rename as after a copy.
If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to "simply work", but not all revision control systems actually do this.)
Whereas having changes follow a copy is a feature where you can perhaps nod and say "yes, that might be useful," it should be clear that having them follow a rename is definitely important. Without this facility, it would simply be too easy for changes to become orphaned when files are renamed.
[^] # Re: Directory rename et merge
Posté par El Titi . En réponse à la dépêche Mercurial : version 1.7 et petit tour d'horizon. Évalué à 3.
Since Mercurial's rename is implemented as copy-and-remove, the same propagation of changes happens when you merge after a rename as after a copy.
If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to "simply work", but not all revision control systems actually do this.)
Whereas having changes follow a copy is a feature where you can perhaps nod and say "yes, that might be useful," it should be clear that having them follow a rename is definitely important. Without this facility, it would simply be too easy for changes to become orphaned when files are renamed.
http://hgbook.red-bean.com/read/mercurial-in-daily-use.html
Ceci s'applique aussi aux répertoires.
En revanche, j'ignorais que git ne savait pas le gérer correctement.