Re: Rename handling

["Martin Langhoff" <martin.langhoff@gmail.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