git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Rename handling

From
APAndy Parkins <andyparkins@gmail.com>
Date
Mar 19, 2007, 19:03 UTC
Message-ID
<200703191903.20005.andyparkins@gmail.com>
In-Reply-To
<45FED31B.8070307@midwinter.com>
On Monday 2007, March 19, Steven Grimm wrote:
> On the other hand, I agree with your general point; I really don't
> like being uncertain about whether renames are going to come out
> correctly or not ("it has always worked before" and "it is by design

I agree with you, but I think that git does exactly what you want. In fact I think git is better.

The beauty of git figuring out renames for itself is that git can figure it out later.

 $ mv file1 file2
 $ git update-index --remove file1
 $ git add file2

The important thing here is that git wasn't used to do the move. This is great when you're lost in a development haze and do the move without thinking.

Show 6 quoted lines
> So to answer your question, in my opinion if 100% guaranteed renames
> are high on your priority list, then Mercurial might be the better
> option for now. In practice, I've found that git's 99+% rename
> detection has yet to fail on me aside from the above directory
> renaming case, but at the end of the day it *is* guessing at your
> renames after the fact.

It's not really a guess; through the magic of sha-1, and provided you are disciplined enough to commit the rename without any changes to the content you can be sure that the rename is tracked. The sha-1 /must/ be the same before and after. For this 100% case, git doesn't even need the "-M", git-blame, git-diff and git-merge will find it anyway.

Even better is that because the rename isn't recorded explicitly when you upgrade git and the detection gets better, all your history instantly gets interpreted correctly.

The only command I've found that doesn't do the "right thing" by default is git-log and I think that once the following works, all the "why doesn't git track renames" people will go quietly away:

 $ git init
 $ date > file1
 $ git add file1
 $ git commit -m ""
 $ git mv file1 file2
 $ git commit -m ""
 $ git mv file2 file3
 $ git commit -m ""
 $ git log -- file3
Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Previous: Daniel BarkalowNext: Steven Grimm
Message 16 of 31 in “Rename handling”
  1. John GoerzenMar 19, 2007
  2. Steven GrimmMar 19, 2007
  3. Nicolas PitreMar 19, 2007
  4. Linus TorvaldsMar 19, 2007
  5. Steven GrimmMar 19, 2007
  6. Martin LanghoffMar 19, 2007
  7. Junio C HamanoMar 20, 2007
  8. Linus TorvaldsMar 19, 2007
  9. Robin RosenbergMar 19, 2007
  10. Linus TorvaldsMar 19, 2007
  11. Steven GrimmMar 19, 2007
  12. Steven GrimmMar 19, 2007
  13. Linus TorvaldsMar 19, 2007
  14. Nicolas PitreMar 19, 2007
  15. Daniel BarkalowMar 19, 2007
  16. Andy ParkinsMar 19, 2007
  17. Steven GrimmMar 19, 2007
  18. Jakub NarebskiMar 21, 2007
  19. Johannes SchindelinMar 21, 2007
  20. Steven GrimmMar 21, 2007
  21. Johannes SchindelinMar 21, 2007
  22. Linus TorvaldsMar 21, 2007
  23. Martin LanghoffMar 22, 2007
  24. Jakub NarebskiMar 22, 2007
  25. Martin LanghoffMar 22, 2007
  26. Jakub NarebskiMar 22, 2007
  27. Linus TorvaldsMar 22, 2007
  28. Daniel BarkalowMar 19, 2007
  29. John GoerzenMar 19, 2007
  30. Junio C HamanoMar 19, 2007
  31. Jakub NarebskiMar 21, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.