Proposed git mv behavioral change

[lmage11@twcny.rr.com]

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