El 20/10/2007, a las 7:55, Ari Entlich escribió:

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

Well, my point was that sometimes you want to rename a dirty file  
*right now* without having your modifications staged in the index  
yet, and only later go ahead and stage the hunks (or the whole file)  
when they're ready.

Basically, without this feature you have to manually unstage the  
stuff that you don't want staged:

[hack on dirty foo]
git mv foo bar
[oops... you just staged unfinished changes]
git reset HEAD bar
[hack until bar is ready]
git add bar

So in order to unstage the stuff that wasn't ready you unstaged the  
whole file and had to re-add it later, in which case what was the  
point of using "git-mv" in the first place? You may as well have just  
done:

[hack on dirty foo]
mv foo bar
[hack until bar is ready]
git rm foo
git add bar

The other alternative is to use git-stash:

[hack on dirty foo]
git stash
git mv foo bar
git stash apply
[hack until bar is ready]
git add bar

So, yes, you can do this with git-stash. It just means that "git-mv -- 
cached" would be a convenient short-cut.

quoted text
> Are you talking about REALLY only changing the index?

No, sorry, I didn't make that clear. I meant that "git mv --cached  
foo bar" would have the following effect (which if I understand it  
correctly is basically what you proposed in your first email):

1. Copying "foo" directly to "bar" (even if dirty).

2. When adding "bar" to the the index add the blob corresponding to  
"foo" as it is staged in the index (or at the HEAD if there are no  
staged changes).

3. Removing the old file "foo".

The actual mechanics of this don't matter; those are just the  
perceived effects. You could get exactly the same perceived effects  
by doing it this way:

1. Creating a new file (or overwriting an existing one) named "bar",  
whose contents would match those of the file "foo" not as it appears  
in the working tree but as it is staged in the index.

2. If "foo" has unstaged changes, they should be applied to "bar" as  
well (but not staged).

3. Removing the old file "foo".

quoted text
> In addition, I don't think giving
> --interactive a filename is meaningful...

Whoops. I think I just inadvertently proposed a feature... my most  
common use of "git-add --interactive" is when I want to stage only  
specific hunks of a particular file, and so instead of typing "git  
add bar" I want to type "git add -i bar" and have it jump straight to  
the "patch" subcommand (5) for that file. Would anyone else find this  
useful?

Cheers,
Wincent


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html