From: Wincent Colaiuta <win@wincent.com>
Date: Fri, 19 Oct 2007 11:33:39 GMT
Subject: Re: Proposed git mv behavioral change
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:

> 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ó:

> 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