Re: Rename handling

> 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.