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

Re: Rename handling

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Mar 22, 2007, 00:10 UTC
Message-ID
<46a038f90703211710q168a691cpa282f8e2afc5c8a6@mail.gmail.com>
In-Reply-To
<4601B199.9060300@midwinter.com>
On 3/22/07, Steven Grimm <koreth@midwinter.com> wrote:
> Say you're tracking a directory full of video files. Even a slight tweak
> to one of them (to put a logo in the corner, say, while moving it into
> an "accessible by the public" directory) will result in a file that has
> no content in common at all if you look at it as purely a stream of

In that case, tracking the rename is not useful at all from the POV of your SCM. The reason the SCM needs to understand content-movement (of which renames are a special type), it to help you as much as possible at merge time.

So - git as an SCM focusses on tracking your content, and helping you merge. It does _that_ probably better than any other SCM. So git internat data structures care strictly about the stuff that is needed for git's operation as an SCM.

And in the context of helping you merge, explicit rename tracking is a red-herring. This point is arguable - Linus said earlier "you can do better by tracking content and ignoring explicit renames" and we are now getting there in terms of having code that does better.

Of course in your case the fact that there was a rename is important
-- for users. This kind of information is not metadata for the SCM but
for users. So that goes into the commit message, which is freeform. So
- working with your scenario, if this happens often, I would suggest
having a pre-commit hook that prepares a nice commit text message
listing likely renames if they can be sussed out automatically.

Or having a custom git-mv that collects mv operations and then your pre-commit-hook preps your commit message with that manifest of moved files.

Does it make sense? It is data-for-the-user, so it goes in the commit msg. If it's data-for-the-SCM machinery, then it goes into the tracking data git handles internally.

cheers,
martin
Previous: Linus TorvaldsNext: Jakub Narebski
Message 23 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.