Why 'hg mv' (mercurial) doesn't move a file's history by default?

13,812

Solution 1

You can can change the default behaviour of log: in your ~/.hgrc (or somewhere/Mercurial.ini), add

[alias] 
log = log -f

I've read the appearance of the log is for speed reason. Move isn't truly a "first level" operation in Mercurial. It's a copy + delete (this compared to Bazaar where the move/rename is a "first level" operation but that doesn't have a copy with history preservation).

Solution 2

You don't know how to do it. hg log --follow affects how the log is displayed, not how the actual move is done. By default, the history of the filename is displayed. --follow follows renames and copies. This fits with how Mercurial is internally implemented.

There is no reason whatsoever to run hg log --follow before hg mv.

Solution 3

The answer of @xantos is now dated. The proper way to update the hgrc file is:

[alias]
log = log -f

13,812

Author by

Somebody still uses you MS-DOS

Just kidding. MS-DOS, you broke my heart. No more.

Updated on June 04, 2022

Comments

Somebody still uses you MS-DOS about 2 years

I know how to do it, I just can't understand why hg mv doesn't move the file's history as well by default.

It really seems silly to be obligated me to run hg log --follow before hg mv. This remembers me the times with cvs when you needed to remove and add a file using two different operations and losing history in the same way.

IMHO, if I were just using builtin mv that would be ok to lose history, but I'm using hg mv, and, thinking about the repository itself, it doesn't make sense to lose the history by default. There should be hg mv --no-follow and not the other way round.

This isn't intuitive. Anyone here has a sane explanation about this behavior? Is this an error by design, or there's really a good reason for it? Is it possible to do this --follow by default someway when using hg mv?
Somebody still uses you MS-DOS over 13 years

@xanatos: Is it possible to create a hook or something that, before doing hg mv, it automatically runs hg log -f?
xanatos over 13 years

No no. The hg log -f only shows the log. The mv is ALWAYS saved as a cp + rm (the same for rename if I remember correctly). You are only forcing the log to work a little more to follow the history of the files.
Matthew Flaschen over 13 years

@xanatos, mv is just an alias for rename.
xanatos over 13 years

@Matthew I suspected it, but I wasn't sure 100%. As an added note, at least on Windows, the graphical interface will show the full log of a copied file (right key on a file, TortoiseHG, Revision History)
tonfa over 13 years

@xanatos (hg dev here): it is FUD from Mark S. that it is more a first level operation in bazaar than in hg. They behave in the same way, it's just that for historical and performance reason we don't follow by default for log (but we do for merges). (Note that Git is actually different from hg and bzr, since it recomputes it every time, both approaches have their merits).
xanatos over 13 years

@tonfa Considering that bzr doesn't have a cp command (and that is the reason I'm now using hg instead of bzr), I fail to see how they could do a cp+rm for a mv :-) ( bugs.launchpad.net/bzr/+bug/269095 )
Somebody still uses you MS-DOS over 13 years

@Matthew Flaschen and @xanatos: Now I got it. In fact, everything makes sense, having the --follow option actually makes more sense than not having it.
R. Oosterholt about 5 years

CAUTION: adding log -f alias to your .hgrc breaks the Mercurial log tab in IntelliJ. See this bug.
R. Oosterholt about 5 years

CAUTION: adding log -f alias to your .hgrc breaks the Mercurial log tab in IntelliJ. See this bug.