Proposed git mv behavioral change

Hey, all...

Based on a question I asked on freenode's #git channel a few days ago, it seems that most people only use git mv when the file they're moving is clean. Those that don't have become accustomed to the behavior that git-mv uses when the file is dirty - to pull all unstaged changes into the index. As far as I can tell, this behavior is largely historical. When git-mv was written in bash (or perl, or whatever it was initially written in), it was most convenient to implement it as "mv oldname newname; git add newname;", or something similar, which would result in pulling in all wd changes. However, it seems to me that this behavior violates git's consistency. Usually when I do something with git, I expect it to do only what it says it will do, and nothing more. The documentation for git-mv says "The index is updated after successful completion", but I would tend to assume that this was referring to the name change and not the change in the actual contents of the file.

In my situation, I have some changes to a file that I'm not yet ready to commit. In the meantime, I've started working on another unrelated change that involves renaming one of the files which contain unstaged changes. I'd like to be able to perform this move without having my unstaged changes implicitly staged without my knowledge. When I want information put into the index, I either use git update-index if I want to explicitly stage an entire file or I use git add -i's patch command to explicitly stage individual chunks. I like having very fine-grained control over what goes into the index and what doesn't.

Therefore, I propose that git mv's behavior be changed. I think it would make far more sense for a move to only change the actual name of the file and to not pull in unstaged changes. In other words, I'd like the index entry for the original file name to be removed and an index entry to be added with a different name, but using the exact same blob hash as the original file. I don't know exactly how git manages the index internally, but a shortcut for this would be to simply rename the index entry in place.

I'm willing to look into what changes would need to be made to the code for this change to happen; I'm not asking for someone to do all the work for me. :)

So... Yeah. I'd like to know what people think about this before I put a significant amount of effort into it. After all, we know how lazy programmers are... :)

Thanks,
   Ari