On 3/22/07, Steven Grimm <koreth@xxxxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html