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

Re: Following renames

From
Linus Torvalds <torvalds@osdl.org>
Date
Mar 26, 2006, 22:22 UTC
Message-ID
<Pine.LNX.4.64.0603261415390.15714@g5.osdl.org>
In-Reply-To
<20060326191445.GQ18185@pasky.or.cz>
On Sun, 26 Mar 2006, Petr Baudis wrote:
Show 10 quoted lines
> 
> My current target is to support this tree (letters are filenames,
> numbers are commit ids; I'll translate any git output to those digits):
> 
>     2    4
>     b -- d
> 1 /        \ 6
> a            d
>   \ 3    5 /
>     c -- d

Yeah, the problem with this is that you need to track separate names across separate points. However:

Show 7 quoted lines
> Curiously, git-rev-list does something totally strange when trying to
> list per-file history at this point:
> 
> 	$ git-rev-list HEAD -- d
> 	4
> 
> Huh? (It should list 6, 5, 4 instead.)
What it does is list the points where file "d" _changed_.

"d" did not change in 6 - it had a parent commit (4) where "d" had the same contents (in fact, it likely had _two_ parents where it had the same contents, but git will pick the first one). So commit "6" is uninteresting, and commit "5" will never even be looked at, since we decided that the history of "d" comes from the first parent with the same contents.

So then it lists "4", because file "d" really did change in that commit (it went away).

Now you need to look at "4" and find the rename (which gives you 2) and then from there you do rename detection and get (1), and as a result your change history should end up being

 (1)a -> (2)b -> (4)d (-> 6(d) which was your start point)

which is correct (now, there are other histories _too_ that get us to the same point, but the one you found this way was _a_ history).

Show 10 quoted lines
> I worked it around by recording a change in d in the merge 6:
> 
> 	http://pasky.or.cz/~xpasky/renametree2.git/
> 
> 	$ git-rev-list --parents --remove-empty HEAD -- d
> 	6 4 5
> 	5
> 	4
> 
> Which is the expected output.

No, it's the expected output just because you expected merges to always show up. Merges get ignored if any of the parents have the same content already.

		Linus
Previous: Petr BaudisNext: Petr Baudis
Message 33 of 41 in “Following renames”
  1. Petr BaudisMar 26, 2006
  2. Junio C HamanoMar 26, 2006
  3. Jakub NarebskiMar 26, 2006
  4. Paul JakmaMar 27, 2006
  5. Petr BaudisMar 26, 2006
  6. Petr BaudisMar 26, 2006
  7. Timo HirvonenMar 26, 2006
  8. Linus TorvaldsMar 26, 2006
  9. Jakub NarebskiMar 26, 2006
  10. Linus TorvaldsMar 26, 2006
  11. Jakub NarebskiMar 26, 2006
  12. Linus TorvaldsMar 26, 2006
  13. Marco CostalbaMar 26, 2006
  14. Linus TorvaldsMar 26, 2006
  15. Marco CostalbaMar 27, 2006
  16. Junio C HamanoMar 27, 2006
  17. Linus TorvaldsMar 27, 2006
  18. Marco CostalbaMar 27, 2006
  19. Johannes SchindelinMar 27, 2006
  20. Linus TorvaldsMar 27, 2006
  21. Marco CostalbaMar 27, 2006
  22. Andreas EricssonMar 27, 2006
  23. Jakub NarebskiMar 27, 2006
  24. David LangMar 27, 2006
  25. Jakub NarebskiMar 27, 2006
  26. Linus TorvaldsMar 26, 2006
  27. Ryan AndersonMar 26, 2006
  28. Petr BaudisMar 26, 2006
  29. Fredrik KuivinenMar 26, 2006
  30. Linus TorvaldsMar 26, 2006
  31. Petr BaudisMar 26, 2006
  32. Petr BaudisMar 26, 2006
  33. Linus TorvaldsMar 26, 2006
  34. Petr BaudisMar 26, 2006
  35. Junio C HamanoMar 26, 2006
  36. Linus TorvaldsMar 26, 2006
  37. Junio C HamanoMar 27, 2006
  38. Linus TorvaldsMar 26, 2006
  39. Petr BaudisMar 26, 2006
  40. Petr BaudisMar 27, 2006
  41. Petr BaudisMar 26, 2006

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.