Re: Proposed git mv behavioral change

From: Wincent Colaiuta <win@wincent.com>
Date: Oct 19, 2007, 11:33 UTC
Message-ID: <28B30BAE-9482-4219-924B-F0EDFB2936FB@wincent.com>
In-Reply-To: <A2491F60-A00E-412A-8389-1C9EB5EDFCEF@mit.edu>

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:

Show 8 quoted lines

> 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).

> 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.

El 19/10/2007, a las 5:47, Jeff King escribió:

Show 5 quoted lines

> 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. I'm thinking of occasions where you just want to do something like:

   git mv --cached foo bar
   git add --interactive bar

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.

Cheers, Wincent