Wow, this seems to me a really weird design choice. Do you have any insight on to why is this? And do you have any idea if this behaviour is tracked to change somewhere? Maybe by project config? Like, one project could opt-in for an actual "rename" history. On 04/08/2025 12:02, Konstantin Khomoutov wrote: > On Mon, Aug 04, 2025 at 02:05:32PM +0000, FMorschel wrote: > >> This is a request to add an –after mode to git mv command to explicitly >> mark a filesystem rename after it has occurred (analogous to mercurial >> => hg mv –after). >> >> This would allow IDE/Language refactor renames/moves and would make sure >> git still detects the moves correctly for keeping the correct commit >> history. > Git does not track renames in the commits in creates, so, basically, if you > have a file foo.txt under the Git's control, and do > > $ git mv foo.txt bar.txt > $ git commit > > The recorded commit will reference a tree object which will - compared > to the tree object of the preceding commit - have an entry for bar.txt > and not have an entry for foo.txt. > > Hence a command like "git mv --after", if implemented, would be a pure > syntactic sugar for "git rm <old_name> && git add <new_name>". >
