Bugzilla – Bug 850
Directory rename inference may lead to unexpected merge result
Last modified: 2012-05-13 04:49:38 EDT
When moving the sole file within a folder "a" to a new folder "b", hg infers folder "a" was renamed to "b". But that was not the intention. A subsequent merge of a new file in "a" moves the new file to "b". #! /bin/bash #rm repo -rf # -- uncomment to make repeatable hg init repo cd repo hg init one cd one mkdir a echo "one" >a/one hg add hg ci -m "one" cd .. hg clone one two cd two echo "two" >a/two hg add hg ci -m "two" cd .. cd one mkdir b hg mv a/one b/one hg ci -m "a2b" hg pull -u ../two hg merge echo "a contains" ls a echo "b contains" ls b
Contrast this with the following, where the intention really was to rename folder "a". This contrast in GUI usage is why pmezard suggested turning this into a bug rather than a wish. Bzr handles this correctly, by the way. #! /bin/bash #rm repo -rf hg init repo cd repo hg init one cd one mkdir a echo "one" >a/one hg add hg ci -m "one" cd .. hg clone one two cd two echo "two" >a/two hg add hg ci -m "two" cd .. cd one hg mv a b hg ci -m "a2b" hg pull -u ../two hg merge ls b
Since we don't track directories, we must *define* a "directory rename" as meaning "all tracked files were moved from one directory to a new directory". In other words: I think this behavior is a consequence of that design decision and there's nothing we should do about this.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:45 EDT --- This bug was previously known as _bug_ 850 at http://mercurial.selenic.com/bts/issue850