Subject: Re: Proposed git mv behavioral change

From: "Shawn O. Pearce" <[email-masked]>
Date: Thu, 18 Oct 2007 21:54:19 -0400

Line wrapping email at under 80 columns would be nice.  It makes it
easier to read the message, and more importantly, easier to quote
a few times during discussion.

[email-masked] wrote:
> 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 somewhat hesistant to change existing behavior, as users may
be used to it or relying upon it within their scripts.  But you
make an excellent argument about why the current git-mv behavior
is perhaps less than ideal.

Elsewhere in git we use the --cached command line option to mean
"only make the change in the index".  For example the git-apply
--cached option.  You could start a patch that uses --cached to
trigger the new behavior you propose and see if people are interested
in changing the default once the feature is working and available
for experimentation.
 
> 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... :)

See builtin-mv.c around l.264-283.  This is where we are removing
the old names from the index (in memory) and inserting the new
names.  Instead of calling add_file_to_cache() you would want
to use something like add_cacheinfo() in builtin-update-index.c,
specifying the old sha1, ce_flags and ce_mode.

I'm sure Junio could probably give you a better starting point
than I can, as he's more familiar with this sort of code, but that
should still get you looking in the right direction and maybe get
a working implementation together that you can share for discussion.

-- 
Shawn.