Re: Proposed git mv behavioral change

[Ari Entlich <lmage11@twcny.rr.com>]

On Fri, 2007-10-19 at 13:33 +0200, Wincent Colaiuta wrote:
> El 19/10/2007, a las 4:29, Michael Witten escribió:
> > Ah. Basically my 'pseudo-code' is correct, but redundant.
> 
> If I understood the original poster's proposal then I don't think your
> code does what he asked for:
> 
> > What you want to happen is the following:
> > 
> > git show HEAD:A.txt > path/B.txt
> > git add path/B.txt
> > mv A.txt B.txt
> > git rm A.txt
> >
> > Is this correct?
> 
> Here you're copying the content of A.txt as it was in the last (HEAD)
> commit, but from what the poster said he wants the content of A.txt as
> it is staged in the index (that is, there may be staged but uncomitted
> changes).

You took the words right out of my mouth! :)

Yeah, I noticed the problem with using HEAD, but the other problem is
that this would change the contents of the file in the working directory
file, which I don't want. Thus, putting the contents of the file as it
is in the index into the working directory wouldn't be correct either.
In addition, I'm not quite sure where that "mv A.txt B.txt" came from,
since we're supposed to be moving A.txt to path/B.txt...

> > Better:
> >
> > > mv A.txt path/B.txt
> > > Point the index entry for A.txt to path/B.txt
> 
> Yes, that is basically what he was asking for, as I read it.

Yep! I was going to respond to your (Michael's) original message saying
exactly that. :)

> El 19/10/2007, a las 5:47, Jeff King escribió:
> > Hrm. So you _do_ want to do an index-only move of A to B, in which 
> > case the suggestion of a "git-mv --cached" seems sensible. Though 
> > I'm curious why you want that.
> 
> I agree that git-stash can be used in this workflow but I can also 
> imagine cases where the proposed "git-mv --cached" might be a bit 
> nicer.

As Shawn said, --cached wouldn't be entirely accurate as the file in the
working directory is being moved as well.

git-stash has been suggested to me numerous times, but I really feel
that there's no need to use it in this case - if the git mv command gave
adequate control to the user, it would be unnecessary.

> I'm thinking of occasions where you just want to do something 
> like:
> 
> git mv --cached foo bar
> git add --interactive bar

I think it would be the other way around, since the only time this
change would effect anything is when there are changes still waiting to
be staged.

Are you talking about REALLY only changing the index? I can't think of
why you'd want to do this either... After all, wouldn't there be no bar
file to do git add --interactive on? In addition, I don't think giving
--interactive a filename is meaningful...

> I'm not sure the proposed "--cached" switch should ever be the 
> default -- would need to ponder that one -- but I do think the switch 
> would be a nice addition.

Yeah, that is one thing I was wondering. It would break compatibility,
but would it be enough to put a note about that in the announcements for
a release? Could you make the change at a release when the interface
isn't guaranteed to be the same, or is this practice only done with
libraries?

It might be interesting to do some sort of survey of whether people
depend on this behavior. It seems pretty inconsistent with how git works
otherwise, and I'd be surprised if a lot of people expect it (kinda like
the Spanish Inquisition :-P).

Thanks,
	Ari