On Sat, Oct 20, 2007 at 01:55:53AM -0400, Ari Entlich wrote: > 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. 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. > > git mv --cached foo bar > 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... 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. > 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). 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
