{"thread":{"id":"10385","subject":"Re: Proposed git mv behavioral change","startedAt":"2007-10-20T05:55:53Z","lastAt":"2007-10-20T11:06:14Z","messageCount":4,"participants":["Ari Entlich","Jeff King","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"56656","messageId":"1192859753.13347.147.camel@g4mdd.entnet","threadId":"10385","inReplyTo":null,"subject":"Re: Proposed git mv behavioral change","fromName":"Ari Entlich","fromEmail":"lmage11@twcny.rr.com","sentAt":"2007-10-20T05:55:53Z","receivedAt":"2007-10-20T05:55:53Z","isPatch":false,"sender":{"key":"lmage11@twcny.rr.com","avatar":null},"body":"On Fri, 2007-10-19 at 13:33 +0200, Wincent Colaiuta wrote:\n> El 19/10/2007, a las 4:29, Michael Witten escribió:\n> > Ah. Basically my 'pseudo-code' is correct, but redundant.\n> \n> If I understood the original poster's proposal then I don't think your\n> code does what he asked for:\n> \n> > What you want to happen is the following:\n> > \n> > git show HEAD:A.txt > path/B.txt\n> > git add path/B.txt\n> > mv A.txt B.txt\n> > git rm A.txt\n> >\n> > Is this correct?\n> \n> Here you're copying the content of A.txt as it was in the last (HEAD)\n> commit, but from what the poster said he wants the content of A.txt as\n> it is staged in the index (that is, there may be staged but uncomitted\n> changes).\n\nYou took the words right out of my mouth! :)\n\nYeah, I noticed the problem with using HEAD, but the other problem is\nthat this would change the contents of the file in the working directory\nfile, which I don't want. Thus, putting the contents of the file as it\nis in the index into the working directory wouldn't be correct either.\nIn addition, I'm not quite sure where that \"mv A.txt B.txt\" came from,\nsince we're supposed to be moving A.txt to path/B.txt...\n\n> > Better:\n> >\n> > > mv A.txt path/B.txt\n> > > Point the index entry for A.txt to path/B.txt\n> \n> Yes, that is basically what he was asking for, as I read it.\n\nYep! I was going to respond to your (Michael's) original message saying\nexactly that. :)\n\n> El 19/10/2007, a las 5:47, Jeff King escribió:\n> > Hrm. So you _do_ want to do an index-only move of A to B, in which \n> > case the suggestion of a \"git-mv --cached\" seems sensible. Though \n> > I'm curious why you want that.\n> \n> I agree that git-stash can be used in this workflow but I can also \n> imagine cases where the proposed \"git-mv --cached\" might be a bit \n> nicer.\n\nAs Shawn said, --cached wouldn't be entirely accurate as the file in the\nworking directory is being moved as well.\n\ngit-stash has been suggested to me numerous times, but I really feel\nthat there's no need to use it in this case - if the git mv command gave\nadequate control to the user, it would be unnecessary.\n\n> I'm thinking of occasions where you just want to do something \n> like:\n> \n> git mv --cached foo bar\n> git add --interactive bar\n\nI think it would be the other way around, since the only time this\nchange would effect anything is when there are changes still waiting to\nbe staged.\n\nAre you talking about REALLY only changing the index? I can't think of\nwhy you'd want to do this either... After all, wouldn't there be no bar\nfile to do git add --interactive on? In addition, I don't think giving\n--interactive a filename is meaningful...\n\n> I'm not sure the proposed \"--cached\" switch should ever be the \n> default -- would need to ponder that one -- but I do think the switch \n> would be a nice addition.\n\nYeah, that is one thing I was wondering. It would break compatibility,\nbut would it be enough to put a note about that in the announcements for\na release? Could you make the change at a release when the interface\nisn't guaranteed to be the same, or is this practice only done with\nlibraries?\n\nIt might be interesting to do some sort of survey of whether people\ndepend on this behavior. It seems pretty inconsistent with how git works\notherwise, and I'd be surprised if a lot of people expect it (kinda like\nthe Spanish Inquisition :-P).\n\nThanks,\n\tAri\n"},{"id":"56661","messageId":"20071020063117.GB30388@coredump.intra.peff.net","threadId":"10385","inReplyTo":"1192859753.13347.147.camel@g4mdd.entnet","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T06:31:17Z","receivedAt":"2007-10-20T06:31:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2007 at 01:55:53AM -0400, Ari Entlich wrote:\n\n> git-stash has been suggested to me numerous times, but I really feel\n> that there's no need to use it in this case - if the git mv command gave\n> adequate control to the user, it would be unnecessary.\n\nYes, now that I understand what you're doing, git-stash is probably\noverkill. It's great if you really want to put aside your current state\nand do some other, totally unrelated work.\n\nBut in this case, you are talking about tools for managing the index\ncorrectly, which is a totally different use case.\n\n> > git mv --cached foo bar\n> Are you talking about REALLY only changing the index? I can't think of\n> why you'd want to do this either... After all, wouldn't there be no bar\n> file to do git add --interactive on? In addition, I don't think giving\n> --interactive a filename is meaningful...\n\nOriginally I had thought git-mv --cached would be useful (and a nice\northogonal design), but it really _does_ seem useless, since it's\nawkward to get your working tree changes into the index without actually\nmoving the working tree file.\n\n> It might be interesting to do some sort of survey of whether people\n> depend on this behavior. It seems pretty inconsistent with how git works\n> otherwise, and I'd be surprised if a lot of people expect it (kinda like\n> the Spanish Inquisition :-P).\n\nThe best way to get comments is to make a patch.\n\nAs for inconsitency of git-mv, it has always been a bit of an odd duck.\nI'm fairly certain neither Linus nor Junio actually use it, preferring\ninstead to make all changes to the working tree and then update the\nindex manually. I even seem to recall Linus arguing that git-mv was\nstupid and unnecessary a long time ago, but I could be wrong.\n\n-Peff\n"},{"id":"56686","messageId":"B6FFD723-83FF-459B-AD00-89DD2A3113DB@wincent.com","threadId":"10385","inReplyTo":"1192859753.13347.147.camel@g4mdd.entnet","subject":"Re: Proposed git mv behavioral change","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-20T11:02:32Z","receivedAt":"2007-10-20T11:02:32Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 20/10/2007, a las 7:55, Ari Entlich escribió:\n\n>> I'm thinking of occasions where you just want to do something\n>> like:\n>>\n>> git mv --cached foo bar\n>> git add --interactive bar\n>\n> I think it would be the other way around, since the only time this\n> change would effect anything is when there are changes still  \n> waiting to\n> be staged.\n\nWell, my point was that sometimes you want to rename a dirty file  \n*right now* without having your modifications staged in the index  \nyet, and only later go ahead and stage the hunks (or the whole file)  \nwhen they're ready.\n\nBasically, without this feature you have to manually unstage the  \nstuff that you don't want staged:\n\n[hack on dirty foo]\ngit mv foo bar\n[oops... you just staged unfinished changes]\ngit reset HEAD bar\n[hack until bar is ready]\ngit add bar\n\nSo in order to unstage the stuff that wasn't ready you unstaged the  \nwhole file and had to re-add it later, in which case what was the  \npoint of using \"git-mv\" in the first place? You may as well have just  \ndone:\n\n[hack on dirty foo]\nmv foo bar\n[hack until bar is ready]\ngit rm foo\ngit add bar\n\nThe other alternative is to use git-stash:\n\n[hack on dirty foo]\ngit stash\ngit mv foo bar\ngit stash apply\n[hack until bar is ready]\ngit add bar\n\nSo, yes, you can do this with git-stash. It just means that \"git-mv -- \ncached\" would be a convenient short-cut.\n\n> Are you talking about REALLY only changing the index?\n\nNo, sorry, I didn't make that clear. I meant that \"git mv --cached  \nfoo bar\" would have the following effect (which if I understand it  \ncorrectly is basically what you proposed in your first email):\n\n1. Copying \"foo\" directly to \"bar\" (even if dirty).\n\n2. When adding \"bar\" to the the index add the blob corresponding to  \n\"foo\" as it is staged in the index (or at the HEAD if there are no  \nstaged changes).\n\n3. Removing the old file \"foo\".\n\nThe actual mechanics of this don't matter; those are just the  \nperceived effects. You could get exactly the same perceived effects  \nby doing it this way:\n\n1. Creating a new file (or overwriting an existing one) named \"bar\",  \nwhose contents would match those of the file \"foo\" not as it appears  \nin the working tree but as it is staged in the index.\n\n2. If \"foo\" has unstaged changes, they should be applied to \"bar\" as  \nwell (but not staged).\n\n3. Removing the old file \"foo\".\n\n> In addition, I don't think giving\n> --interactive a filename is meaningful...\n\nWhoops. I think I just inadvertently proposed a feature... my most  \ncommon use of \"git-add --interactive\" is when I want to stage only  \nspecific hunks of a particular file, and so instead of typing \"git  \nadd bar\" I want to type \"git add -i bar\" and have it jump straight to  \nthe \"patch\" subcommand (5) for that file. Would anyone else find this  \nuseful?\n\nCheers,\nWincent\n"},{"id":"56687","messageId":"20071020110614.GA19023@sigill.intra.peff.net","threadId":"10385","inReplyTo":"B6FFD723-83FF-459B-AD00-89DD2A3113DB@wincent.com","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T11:06:14Z","receivedAt":"2007-10-20T11:06:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2007 at 01:02:32PM +0200, Wincent Colaiuta wrote:\n\n> Whoops. I think I just inadvertently proposed a feature... my most common \n> use of \"git-add --interactive\" is when I want to stage only specific hunks \n> of a particular file, and so instead of typing \"git add bar\" I want to type \n> \"git add -i bar\" and have it jump straight to the \"patch\" subcommand (5) for \n> that file. Would anyone else find this useful?\n\nYes, my only use of git-add --interactive is to stage particular patches\nfrom individual files. So I would find that feature useful.\n\n-Peff\n"}]}