Re: Proposed git mv behavioral change

On Fri, 2007-10-19 at 13:33 +0200, Wincent Colaiuta wrote:

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

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

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

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

On Sat, Oct 20, 2007 at 01:55:53AM -0400, Ari Entlich wrote:

Yes, now that I understand what you're doing, git-stash is probably overkill. It's great if you really want to put aside your current state and do some other, totally unrelated work.

But in this case, you are talking about tools for managing the index correctly, which is a totally different use case.

Originally I had thought git-mv --cached would be useful (and a nice orthogonal design), but it really _does_ seem useless, since it's awkward to get your working tree changes into the index without actually moving the working tree file.

The best way to get comments is to make a patch.

As for inconsitency of git-mv, it has always been a bit of an odd duck. I'm fairly certain neither Linus nor Junio actually use it, preferring instead to make all changes to the working tree and then update the index manually. I even seem to recall Linus arguing that git-mv was stupid and unnecessary a long time ago, but I could be wrong.

-Peff

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

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.

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

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

On Sat, Oct 20, 2007 at 01:02:32PM +0200, Wincent Colaiuta wrote:

Yes, my only use of git-add --interactive is to stage particular patches from individual files. So I would find that feature useful.

-Peff