On Fri, 2007-10-19 at 13:33 +0200, Wincent Colaiuta wrote: > 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). 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... > > 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. Yep! I was going to respond to your (Michael's) original message saying exactly that. :) > 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. 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'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. 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... > 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. 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 - 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
