{"thread":{"id":"10361","subject":"Proposed git mv behavioral change","startedAt":"2007-10-18T15:47:32Z","lastAt":"2007-10-22T14:08:41Z","messageCount":34,"participants":["lmage11@twcny.rr.com","Michael Witten","Shawn O. Pearce","Jeff King","Wincent Colaiuta","Ari Entlich","Mike Hommey","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"56407","messageId":"c594999b2337.2337c594999b@nyroc.rr.com","threadId":"10361","inReplyTo":null,"subject":"Proposed git mv behavioral change","fromName":"","fromEmail":"lmage11@twcny.rr.com","sentAt":"2007-10-18T15:47:32Z","receivedAt":"2007-10-18T15:47:32Z","isPatch":false,"sender":{"key":"lmage11@twcny.rr.com","avatar":null},"body":"Hey, all...\n\nBased on a question I asked on freenode's #git channel a few days ago, it seems that most \npeople only use git \nmv when the file they're moving is clean. Those that don't have become accustomed to the \nbehavior that git-mv \nuses when the file is dirty - to pull all unstaged changes into the index. As far as I can tell, \nthis behavior is \nlargely historical. When git-mv was written in bash (or perl, or whatever it was initially written \nin), it was most \nconvenient to implement it as \"mv oldname newname; git add newname;\", or something \nsimilar, which would \nresult in pulling in all wd changes. However, it seems to me that this behavior violates git's \nconsistency. Usually \nwhen I do something with git, I expect it to do only what it says it will do, and nothing more. \nThe \ndocumentation for git-mv says \"The index is updated after successful completion\", but I \nwould tend to assume \nthat this was referring to the name change and not the change in the actual contents of the \nfile.\n\nIn my situation, I have some changes to a file that I'm not yet ready to commit. In the \nmeantime, I've started \nworking on another unrelated change that involves renaming one of the files which contain \nunstaged changes. \nI'd like to be able to perform this move without having my unstaged changes implicitly \nstaged without my \nknowledge. When I want information put into the index, I either use git update-index if I \nwant to explicitly \nstage an entire file or I use git add -i's patch command to explicitly stage individual chunks. I \nlike having very \nfine-grained control over what goes into the index and what doesn't.\n\nTherefore, I propose that git mv's behavior be changed. I think it would make far more sense \nfor a move to only \nchange the actual name of the file and to not pull in unstaged changes. In other words, I'd \nlike the index entry \nfor the original file name to be removed and an index entry to be added with a different \nname, but using the \nexact same blob hash as the original file. I don't know exactly how git manages the index \ninternally, but a \nshortcut for this would be to simply rename the index entry in place.\n\nI'm willing to look into what changes would need to be made to the code for this change to \nhappen; I'm not \nasking for someone to do all the work for me. :)\n\nSo... Yeah. I'd like to know what people think about this before I put a significant amount of \neffort into it. After \nall, we know how lazy programmers are... :)\n\nThanks,\n Ari\n"},{"id":"56464","messageId":"D2EAAC6D-567D-454A-AECA-C90FA2C369AE@mit.edu","threadId":"10361","inReplyTo":"c594999b2337.2337c594999b@nyroc.rr.com","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T01:47:12Z","receivedAt":"2007-10-19T01:47:12Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:\n\n> I don't know exactly how git manages the index\n> internally, but a\n> shortcut for this would be to simply rename the index entry in place.\n\nSeems like the shortcut would lose the history and confuse git.\n\nAnyway,\n\nLet's say you have a file, A.txt, with contents:\n\n\tA\n\nYou edit this file so that it has contents:\n\t\n\tA_dirty\n\nYou're saying that, currently, 'git-mv A.txt path/B.txt'\ndoes this:\n\t\n\tmv A.txt path/B.txt\n\tgit add path/B.txt\n\tgit rm A.txt\n\nSo that A.txt is indeed moved to path/B.txt, but now\nA_dirty has been added to the index.\n\nWhat you want to happen is the following:\n\t\n\tgit show HEAD:A.txt > path/B.txt\n\tgit add path/B.txt\n\tmv A.txt B.txt\n\tgit rm A.txt\n\nIs this correct?\n\nMichael Witten\n"},{"id":"56465","messageId":"20071019015419.GV14735@spearce.org","threadId":"10361","inReplyTo":"c594999b2337.2337c594999b@nyroc.rr.com","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T01:54:19Z","receivedAt":"2007-10-19T01:54:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Line wrapping email at under 80 columns would be nice. It makes it\neasier to read the message, and more importantly, easier to quote\na few times during discussion.\n\nlmage11@twcny.rr.com wrote:\n> Therefore, I propose that git mv's behavior be changed. I think it\n> would make far more sense for a move to only change the actual name\n> of the file and to not pull in unstaged changes. In other words,\n> I'd like the index entry for the original file name to be removed\n> and an index entry to be added with a different name, but using the\n> exact same blob hash as the original file. I don't know exactly how\n> git manages the index internally, but a shortcut for this would be\n> to simply rename the index entry in place.\n\nI'm somewhat hesistant to change existing behavior, as users may\nbe used to it or relying upon it within their scripts. But you\nmake an excellent argument about why the current git-mv behavior\nis perhaps less than ideal.\n\nElsewhere in git we use the --cached command line option to mean\n\"only make the change in the index\". For example the git-apply\n--cached option. You could start a patch that uses --cached to\ntrigger the new behavior you propose and see if people are interested\nin changing the default once the feature is working and available\nfor experimentation.\n \n> I'm willing to look into what changes would need to be made to the\n> code for this change to happen; I'm not asking for someone to do\n> all the work for me. :)\n> \n> So... Yeah. I'd like to know what people think about this before\n> I put a significant amount of effort into it. After all, we know\n> how lazy programmers are... :)\n\nSee builtin-mv.c around l.264-283. This is where we are removing\nthe old names from the index (in memory) and inserting the new\nnames. Instead of calling add_file_to_cache() you would want\nto use something like add_cacheinfo() in builtin-update-index.c,\nspecifying the old sha1, ce_flags and ce_mode.\n\nI'm sure Junio could probably give you a better starting point\nthan I can, as he's more familiar with this sort of code, but that\nshould still get you looking in the right direction and maybe get\na working implementation together that you can share for discussion.\n\n-- \nShawn.\n"},{"id":"56466","messageId":"20071019015715.GW14735@spearce.org","threadId":"10361","inReplyTo":"D2EAAC6D-567D-454A-AECA-C90FA2C369AE@mit.edu","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T01:57:15Z","receivedAt":"2007-10-19T01:57:15Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael Witten wrote:\n> On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:\n> \n> >I don't know exactly how git manages the index\n> >internally, but a\n> >shortcut for this would be to simply rename the index entry in place.\n> \n> Seems like the shortcut would lose the history and confuse git.\n\nNo. It wouldn't. The index has no knowledge of history of anything.\nFor good reason. Its strictly a mapping of file name to some basic\nstat information (used to determine if the file has been modified\nby the user or not) and the SHA-1 of the staged blob. That's it.\nNo history. The shortcut the original poster was asking about\nwouldn't confuse Git one bit.\n \n-- \nShawn.\n"},{"id":"56469","messageId":"7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU","threadId":"10361","inReplyTo":"20071019015715.GW14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T02:07:05Z","receivedAt":"2007-10-19T02:07:05Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:\n\n> Michael Witten wrote:\n>> On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:\n>>\n>>> I don't know exactly how git manages the index\n>>> internally, but a\n>>> shortcut for this would be to simply rename the index entry in \n>>> place.\n>>\n>> Seems like the shortcut would lose the history and confuse git.\n>\n> No. It wouldn't. The index has no knowledge of history of anything.\n\nI mean to say, if only the index is changed,\nthen git won't be informed about the necessary\ngit-{add/rm}'s, as in the following (is this\nnot so?):\n\n> You're saying that, currently, 'git-mv A.txt path/B.txt'\n> does this:\n> \t\n> \tmv A.txt path/B.txt\n> \tgit add path/B.txt\n> \tgit rm A.txt\n>\n> So that A.txt is indeed moved to path/B.txt, but now\n> A_dirty has been added to the index.\n>\n> What you want to happen is the following:\n> \t\n> \tgit show HEAD:A.txt > path/B.txt\n> \tgit add path/B.txt\n> \tmv A.txt B.txt\n> \tgit rm A.txt\n"},{"id":"56471","messageId":"20071019021529.GX14735@spearce.org","threadId":"10361","inReplyTo":"7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T02:15:29Z","receivedAt":"2007-10-19T02:15:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael Witten wrote:\n> On 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:\n> >Michael Witten wrote:\n> >>\n> >>Seems like the shortcut would lose the history and confuse git.\n> >\n> >No. It wouldn't. The index has no knowledge of history of anything.\n> \n> I mean to say, if only the index is changed,\n> then git won't be informed about the necessary\n> git-{add/rm}'s, as in the following (is this\n> not so?):\n\ngit-add amounts to either inserting a new path->stat/sha1 entry\nin the index, or updating an existing entry with new stat/sha1\ninformation.\n\ngit-rm amounts to removing a path->stat/sha1 entry from the index.\nIt's just gone once the git-rm is completed. As if it was never\nthere to begin with.\n\nA git-commit (really git-write-tree but same difference to the\nend-user) stores whatever is in the index as the gospel truth for\nhow that commit's files should appear. No knowledge about add\nor rm is necessary at this stage, we're just taking a copy of the\nindex and recording that for posterity.\n\nSo updating the index is all that is necessary to \"remember\" these\nadd and rm operations. OK, well, you also need to actually make\na commit (and not orphan that commit) to have it really stay in\nyour project. But its all really as simple as it seems.\n\n-- \nShawn.\n"},{"id":"56472","messageId":"20071019021618.GE3290@coredump.intra.peff.net","threadId":"10361","inReplyTo":"7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T02:16:18Z","receivedAt":"2007-10-19T02:16:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 10:07:05PM -0400, Michael Witten wrote:\n\n> I mean to say, if only the index is changed,\n> then git won't be informed about the necessary\n> git-{add/rm}'s, as in the following (is this\n> not so?):\n\nEh? The changes will make it into history when you commit. Or perhaps I\ndon't understand your question. Can you rephrase it?\n\n-Peff\n"},{"id":"56478","messageId":"A2491F60-A00E-412A-8389-1C9EB5EDFCEF@mit.edu","threadId":"10361","inReplyTo":"20071019021618.GE3290@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T02:29:28Z","receivedAt":"2007-10-19T02:29:28Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 10:15:29 PM, Shawn O. Pearce wrote:\n> git-add amounts to either inserting a new path->stat/sha1 entry\n> in the index, or updating an existing entry with new stat/sha1\n> information.\n>\n> git-rm amounts to removing a path->stat/sha1 entry from the index.\n> It's just gone once the git-rm is completed. As if it was never\n> there to begin with.\n>\n> A git-commit (really git-write-tree but same difference to the\n> end-user) stores whatever is in the index as the gospel truth for\n> how that commit's files should appear.\n\nAh. Basically my 'pseudo-code' is correct, but redundant.\n\n\nOn 18 Oct 2007, at 10:16:18 PM, Jeff King wrote:\n> Eh? The changes will make it into history when you commit. Or \n> perhaps I\n> don't understand your question. Can you rephrase it?\n\nI misunderstood the (lack) of details.\n\nOn 18 Oct 2007, at 10:15:29 PM, Shawn O. Pearce wrote:\n> But its all really as simple as it seems.\n\nIt's about time I read more thoroughly through the manual!\n\nThanks.\n"},{"id":"56491","messageId":"A2C1BF08-4CC8-4F98-9CA8-B81B2FBFE9E4@mit.edu","threadId":"10361","inReplyTo":"20071019015419.GV14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T02:54:19Z","receivedAt":"2007-10-19T02:54:19Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 9:54:19 PM, Shawn O. Pearce wrote:\n\n> Elsewhere in git we use the --cached command line option to mean\n> \"only make the change in the index\".\n\n\nIt seems like --cached should be phased out in favor of --index/ed\n"},{"id":"56496","messageId":"20071019031959.GE14735@spearce.org","threadId":"10361","inReplyTo":"A2C1BF08-4CC8-4F98-9CA8-B81B2FBFE9E4@mit.edu","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T03:19:59Z","receivedAt":"2007-10-19T03:19:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael Witten wrote:\n> \n> On 18 Oct 2007, at 9:54:19 PM, Shawn O. Pearce wrote:\n> \n> >Elsewhere in git we use the --cached command line option to mean\n> >\"only make the change in the index\".\n> \n> It seems like --cached should be phased out in favor of --index/ed\n\nNo, --index is something else.\n\nBut I was originally *way* wrong to propose --cached for this usage\nin git-mv. --cached means \"apply *ONLY* to the index\" and \"do *NOT*\ntouch the working tree\". Here we want to touch the working tree\nin the sense of moving the file. So --cached is not the correct\noption name.\n\n--index is used in Git for places were we update *both* the index\nand the working directory (git-apply --index). So actually I should\nhave suggested \"git-mv --index\". Whoops.\n\n-- \nShawn.\n"},{"id":"56497","messageId":"20071019032407.GA10622@coredump.intra.peff.net","threadId":"10361","inReplyTo":"20071019031959.GE14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:24:07Z","receivedAt":"2007-10-19T03:24:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:19:59PM -0400, Shawn O. Pearce wrote:\n\n> touch the working tree\". Here we want to touch the working tree\n> in the sense of moving the file. So --cached is not the correct\n> option name.\n\nDoesn't \"mv\" do that?\n\n-Peff\n"},{"id":"56499","messageId":"7E3647F4-E61C-4FBE-9AA7-81CDBE324308@MIT.EDU","threadId":"10361","inReplyTo":"20071019032407.GA10622@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T03:26:32Z","receivedAt":"2007-10-19T03:26:32Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 11:24:07 PM, Jeff King wrote:\n\n> On Thu, Oct 18, 2007 at 11:19:59PM -0400, Shawn O. Pearce wrote:\n>\n>> touch the working tree\". Here we want to touch the working tree\n>> in the sense of moving the file. So --cached is not the correct\n>> option name.\n>\n> Doesn't \"mv\" do that?\n\nWe only want to move it, not also add its dirty contents.\n"},{"id":"56503","messageId":"20071019033500.GB10697@coredump.intra.peff.net","threadId":"10361","inReplyTo":"7E3647F4-E61C-4FBE-9AA7-81CDBE324308@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:35:00Z","receivedAt":"2007-10-19T03:35:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:26:32PM -0400, Michael Witten wrote:\n\n>>> touch the working tree\". Here we want to touch the working tree\n>>> in the sense of moving the file. So --cached is not the correct\n>>> option name.\n>>\n>> Doesn't \"mv\" do that?\n>\n> We only want to move it, not also add its dirty contents.\n\nRight, I mean regular \"mv\", not \"git-mv\". The only thing that doesn't\naccomplish is moving the \"from\" entry in the index to the \"to\" entry\n(but I'm not sure that's such a good idea). Perhaps I've lost sight of\nyour original goal. Can you state more succintly what you are trying to\naccomplish?\n\n-Peff\n"},{"id":"56505","messageId":"93BF5798-F1C3-48EE-8233-A0F111BF8138@MIT.EDU","threadId":"10361","inReplyTo":"20071019033500.GB10697@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T03:40:47Z","receivedAt":"2007-10-19T03:40:47Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 11:35:00 PM, Jeff King wrote:\n\n> Right, I mean regular \"mv\", not \"git-mv\". The only thing that doesn't\n> accomplish is moving the \"from\" entry in the index to the \"to\" entry\n> (but I'm not sure that's such a good idea). Perhaps I've lost \n> sight of\n> your original goal. Can you state more succintly what you are \n> trying to\n> accomplish?\n\nI think you're right.\n\nAnyway, succinctly:\n\n> What you want to happen is the following:\n> \t\n> \tgit show HEAD:A.txt > path/B.txt\n> \tgit add path/B.txt\n> \tmv A.txt B.txt\n> \tgit rm A.txt\n\nBetter:\n\n> \tmv A.txt path/B.txt\n> \tPoint the index entry for A.txt to path/B.txt\n\nI hope that's right.\n"},{"id":"56508","messageId":"20071019034704.GB11095@coredump.intra.peff.net","threadId":"10361","inReplyTo":"93BF5798-F1C3-48EE-8233-A0F111BF8138@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:47:05Z","receivedAt":"2007-10-19T03:47:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:40:47PM -0400, Michael Witten wrote:\n\n> Anyway, succinctly:\n>\n>> What you want to happen is the following:\n>> \t\n>> \tgit show HEAD:A.txt > path/B.txt\n>> \tgit add path/B.txt\n>> \tmv A.txt B.txt\n>> \tgit rm A.txt\n>\n> Better:\n>\n>> \tmv A.txt path/B.txt\n>> \tPoint the index entry for A.txt to path/B.txt\n>\n> I hope that's right.\n\nHrm. So you _do_ want to do an index-only move of A to B, in which case\nthe suggestion of a \"git-mv --cached\" seems sensible. Though I'm curious\nwhy you want that. The only workflow I can think of is:\n\n 1. you modify a.c\n 2. your boss comes in and tells you to make some unrelated change,\n which involves moving a.c to b.c\n 3. You don't want to commit your changes, so you git-mv in the index\n only without involving your dirty working tree file.\n 4. You commit the index (which doesn't have your changes from (1)\n\nI think that is sort of a bogus workflow, though, since you will never\nhave actually compiled or tested the changes in (2). You are much better\nto git-stash your current work, fulfill the boss's request, then\nunstash.\n\n-Peff\n"},{"id":"56510","messageId":"C5184350-51A7-46B4-B0C9-E32F79214546@MIT.EDU","threadId":"10361","inReplyTo":"20071019034704.GB11095@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T03:53:05Z","receivedAt":"2007-10-19T03:53:05Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 18 Oct 2007, at 11:47:05 PM, Jeff King wrote:\n\n> The only workflow I can think of is:\n>\n> 1. you modify a.c\n> 2. your boss comes in and tells you to make some unrelated change,\n> which involves moving a.c to b.c\n> 3. You don't want to commit your changes, so you git-mv in the index\n> only without involving your dirty working tree file.\n> 4. You commit the index (which doesn't have your changes from (1)\n>\n> I think that is sort of a bogus workflow\n\nHa!\n\nThat's exactly what the original poster wanted.\n\nIt's not unreasonable.\n"},{"id":"56512","messageId":"20071019035838.GB18717@coredump.intra.peff.net","threadId":"10361","inReplyTo":"C5184350-51A7-46B4-B0C9-E32F79214546@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T03:58:38Z","receivedAt":"2007-10-19T03:58:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 11:53:05PM -0400, Michael Witten wrote:\n\n>> 3. You don't want to commit your changes, so you git-mv in the index\n>> only without involving your dirty working tree file.\n> That's exactly what the original poster wanted.\n>\n> It's not unreasonable.\n\nI guess. I really think git-stash is your friend here. But you can still\ndo step (3) with git-update-index (I'll leave the exact details as an\nexercise for the reader).\n\n-Peff\n"},{"id":"56559","messageId":"28B30BAE-9482-4219-924B-F0EDFB2936FB@wincent.com","threadId":"10361","inReplyTo":"A2491F60-A00E-412A-8389-1C9EB5EDFCEF@mit.edu","subject":"Re: Proposed git mv behavioral change","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-19T11:33:39Z","receivedAt":"2007-10-19T11:33:39Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 19/10/2007, a las 4:29, Michael Witten escribió:\n\n> Ah. Basically my 'pseudo-code' is correct, but redundant.\n\nIf I understood the original poster's proposal then I don't think \nyour code does what he asked for:\n\n> What you want to happen is the following:\n> \t\n> \tgit show HEAD:A.txt > path/B.txt\n> \tgit add path/B.txt\n> \tmv A.txt B.txt\n> \tgit rm A.txt\n>\n> Is this correct?\n\nHere you're copying the content of A.txt as it was in the last (HEAD) \ncommit, but from what the poster said he wants the content of A.txt \nas it is staged in the index (that is, there may be staged but \nuncomitted changes).\n\n> Better:\n>\n>> \tmv A.txt path/B.txt\n>> \tPoint the index entry for A.txt to path/B.txt\n\nYes, that is basically what he was asking for, as I read it.\n\nEl 19/10/2007, a las 5:47, Jeff King escribió:\n\n> Hrm. So you _do_ want to do an index-only move of A to B, in which \n> case\n> the suggestion of a \"git-mv --cached\" seems sensible. Though I'm \n> curious\n> why you want that.\n\nI agree that git-stash can be used in this workflow but I can also \nimagine cases where the proposed \"git-mv --cached\" might be a bit \nnicer. I'm thinking of occasions where you just want to do something \nlike:\n\n git mv --cached foo bar\n git add --interactive bar\n\nI'm not sure the proposed \"--cached\" switch should ever be the \ndefault -- would need to ponder that one -- but I do think the switch \nwould be a nice addition.\n\nCheers,\nWincent\n"},{"id":"56598","messageId":"9E5BD9E5-9027-4F92-8E32-BF78BA25321C@MIT.EDU","threadId":"10361","inReplyTo":"28B30BAE-9482-4219-924B-F0EDFB2936FB@wincent.com","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-19T15:57:22Z","receivedAt":"2007-10-19T15:57:22Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 19 Oct 2007, at 7:33:39 AM, Wincent Colaiuta wrote:\n\n>> What you want to happen is the following:\n>> \t\n>> \tgit show HEAD:A.txt > path/B.txt\n>> \tgit add path/B.txt\n>> \tmv A.txt B.txt\n>> \tgit 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 \n> (HEAD) commit, but from what the poster said he wants the content \n> of A.txt as it is staged in the index (that is, there may be staged \n> but uncomitted changes).\n>\n>> Better:\n>>\n>>> \tmv A.txt path/B.txt\n>>> \tPoint 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\nYou're right.\n\nThere is the subtlety in the first case that he's already staged \nsomething.\n"},{"id":"56655","messageId":"1192859748.13347.146.camel@g4mdd.entnet","threadId":"10361","inReplyTo":"20071019034704.GB11095@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Ari Entlich","fromEmail":"lmage11@twcny.rr.com","sentAt":"2007-10-20T05:55:48Z","receivedAt":"2007-10-20T05:55:48Z","isPatch":false,"sender":{"key":"lmage11@twcny.rr.com","avatar":null},"body":"On Thu, 2007-10-18 at 23:47 -0400, Jeff King wrote: \n> On Thu, Oct 18, 2007 at 11:40:47PM -0400, Michael Witten wrote:\n> \n> > Anyway, succinctly:\n> >\n> >> What you want to happen is the following:\n> >> \t\n> >> \tgit show HEAD:A.txt > path/B.txt\n> >> \tgit add path/B.txt\n> >> \tmv A.txt B.txt\n> >> \tgit rm A.txt\n\nThe one above is not only \"worse\" than the one below, it's wrong. See\nWincent's message and my response to it.\n\n> >\n> > Better:\n> >\n> >> \tmv A.txt path/B.txt\n> >> \tPoint the index entry for A.txt to path/B.txt\n> >\n> > I hope that's right.\n> \n> Hrm. So you _do_ want to do an index-only move of A to B, in which case\n> the suggestion of a \"git-mv --cached\" seems sensible. Though I'm curious\n> why you want that.\n\nWell, I also want to move the working directory file so that the index\nand the working directory still match up and so that their differences\nare preserved. Therefore, --cached isn't quite right (see Shawn's\nmessages and my response to them).\n\n> The only workflow I can think of is: \n> 1. you modify a.c\n> 2. your boss comes in and tells you to make some unrelated change,\n> which involves moving a.c to b.c\n> 3. You don't want to commit your changes, so you git-mv in the index\n> only without involving your dirty working tree file.\n> 4. You commit the index (which doesn't have your changes from (1)\n> \n> I think that is sort of a bogus workflow, though, since you will never\n> have actually compiled or tested the changes in (2). You are much better\n> to git-stash your current work, fulfill the boss's request, then\n> unstash.\n\nHmm, that's an interesting point. Are you talking about situations in\nwhich your changes after (1) leave the program in an uncompilable state?\nIn this situation, I could imagine git stash being a better solution. In\nmy situation, however, the project was compilable. The reason I didn't\nwant to commit the changes was because I wasn't entirely satisfied with\nhow I implemented the change I was trying to make; I thought there might\nbe a better way to do it. I wanted to get some comparatively\nstraightforward changes out of the way before I tackled it.\n\nOn some level, the reason I want this change isn't entirely because it's\npreventing me from doing something I want to do. I've come to really\nlike git and how the index can be used to separate all of the changes\nyou have made from the changes that you want to commit in individual\ncommits. I've come to really like how much access to the lower-level\ninterfaces git provides. It seems to me that people should support this\nsimply because it provides more power to the user. If the user wants\ntheir unstaged changes to be staged, they can explicitly do it with git\nupdate-index or some such command.\n\nIf the issue is whether this would be the default, that's a completely\nseparate issue, and one which I don't really have a strong opinion on.\nIf it were up to me, I'd probably choose to make it the default, but\nthis might break some people's expectations. I want to keep git\naccessible to as many people as possible, not force it into the mold\nthat I feel is the only correct one. If the functionality is available\nbut only used when you want it, what's the harm in including it?\n\nI don't really see why you're analyzing the situations in which this\nwould be used. I think it should be obvious from my descriptions of my\nsituation that there is an application for this functionality. Unless\nyou're going to start calling my process bogus (as you did to the one\ninvolving a boss), which I would not appreciate, I'd argue that the same\nmentality should be applied to this that is applied to kernel drivers -\nif it's useful to even only one person, it should be supported. This\nfunctionality of git wouldn't even be that extreme an example, though -\nthere's no telling whether somebody might be in a situation like mine\nand find that they want to do what I want to do.\n\nBut... that's not even the point I was going to make. I think the\nquestions you should be asking are things like \"Does this fit with the\noverall architecture?\", \"Does this or doesn't this provide power and\nflexibility to the user?\", etc. Is git being made for \"the 80%\" that use\nSubversion and need to be supported by a cushy GUI, or \"the 20%\" that\nthrive on power and are in touch with future trends?\n\nSo... yeah. Sorry, I know this got to sounding incredibly\npropagandistic, but this is what propaganda's for, right? :)\n\nSorry if anything I've said here sounded confrontational; that was not\nnot my intent at all. I'm just raising some points I think are\nimportant. I don't want any flame wars...\n\nOn Thu, 2007-10-18 at 23:58 -0400, Jeff King wrote:\n> On Thu, Oct 18, 2007 at 11:53:05PM -0400, Michael Witten wrote:\n> > It's not unreasonable.\n> \n> I guess. I really think git-stash is your friend here. But you can\n> still do step (3) with git-update-index (I'll leave the exact details\n> as an exercise for the reader).\n\nSee my response to Wincent's message for my opinion on using git stash.\nI seems to me that using it is more of a workaround than a fix.\n\nThanks,\n\tAri\n"},{"id":"56657","messageId":"1192859758.13347.148.camel@g4mdd.entnet","threadId":"10361","inReplyTo":"20071019015419.GV14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Ari Entlich","fromEmail":"lmage11@twcny.rr.com","sentAt":"2007-10-20T05:55:58Z","receivedAt":"2007-10-20T05:55:58Z","isPatch":false,"sender":{"key":"lmage11@twcny.rr.com","avatar":null},"body":"On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:\n> Line wrapping email at under 80 columns would be nice. It makes it\n> easier to read the message, and more importantly, easier to quote\n> a few times during discussion.\n\nYeah, sorry about that. As I said, the crappy webmail client I was using\nwas screwing up. I'm using a real email client now.\n\n> I'm somewhat hesistant to change existing behavior, as users may\n> be used to it or relying upon it within their scripts. But you\n> make an excellent argument about why the current git-mv behavior\n> is perhaps less than ideal.\n\nSee my response to Wincent's message for what I said about this.\n\nOne minor issue (since you talk about programming stuff below) is that,\nfrom my cursory survey of builtin-mv.c, a slight restructuring might be\nrequired for this to work and for the solution to satisfy my coding\nstandards. This would be because you'd need to change the names of\nindividual cache entries as opposed to removing one and adding one. This\nis a minor issue though, I'm sure I can figure out how to get it to work\nsomehow.\n\n> Elsewhere in git we use the --cached command line option to mean\n> \"only make the change in the index\". For example the git-apply\n> --cached option. You could start a patch that uses --cached to\n> trigger the new behavior you propose and see if people are interested\n> in changing the default once the feature is working and available\n> for experimentation.\n\n>From a later email...\n> But I was originally *way* wrong to propose --cached for this usage\n> in git-mv. --cached means \"apply *ONLY* to the index\" and \"do *NOT*\n> touch the working tree\". Here we want to touch the working tree\n> in the sense of moving the file. So --cached is not the correct\n> option name.\n\nHmm yeah, that did occur to me after I read your original message...\n\n> --index is used in Git for places were we update *both* the index\n> and the working directory (git-apply --index). So actually I should\n> have suggested \"git-mv --index\". Whoops.\n\nAlright then, I don't know about that particular convention. If this\nbehavior can't be made default, git mv --index should activate it? I\nthere anything else that might be more descriptive?\n\n> > I'm willing to look into what changes would need to be made to the\n> > code for this change to happen; I'm not asking for someone to do\n> > all the work for me. :)\n> > \n> > So... Yeah. I'd like to know what people think about this before\n> > I put a significant amount of effort into it. After all, we know\n> > how lazy programmers are... :)\n> \n> See builtin-mv.c around l.264-283. This is where we are removing\n> the old names from the index (in memory) and inserting the new\n> names. Instead of calling add_file_to_cache() you would want\n> to use something like add_cacheinfo() in builtin-update-index.c,\n> specifying the old sha1, ce_flags and ce_mode.\n\nMight it be possible to simply get the struct cache_entry for the file\nwhich we want to rename, change its name property (would this involve\nxreallocing it?), and change the ce_namelen field of ce_flags?\n\nIn any case, I think the ce_flags would need to be changed to reflect\nthe new name length. Also, it seems that the old ce_mtime, ce_dev,\nce_ino, ce_uid, ce_gid, and ce_size could be used too... ce_ctime would\nneed to be updated...\n\n> I'm sure Junio could probably give you a better starting point\n> than I can, as he's more familiar with this sort of code, but that\n> should still get you looking in the right direction and maybe get\n> a working implementation together that you can share for discussion.\n\nYeah, I'd appreciate any help I can get. The people on #git were\ninvoking the \"the code is the documentation\" ideology. :)\n\nSo... Ping Junio...? I actually haven't seen any messages from him since\nI subscribed to this list (I've only gotten about 300 messages so far,\nbut I'd expect to see a lot from him as he's the maintainer...). Is he\naway at the moment or something?\n\nThanks,\n\tAri\n"},{"id":"56659","messageId":"20071020062400.GA30388@coredump.intra.peff.net","threadId":"10361","inReplyTo":"1192859748.13347.146.camel@g4mdd.entnet","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T06:24:00Z","receivedAt":"2007-10-20T06:24:00Z","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:48AM -0400, Ari Entlich wrote:\n\n> Well, I also want to move the working directory file so that the index\n> and the working directory still match up and so that their differences\n> are preserved. Therefore, --cached isn't quite right (see Shawn's\n> messages and my response to them).\n\nAh, OK. I understand now. So what you would want could be accomplished\nwith something like:\n\n mv A B\n (git-ls-files -s | sed s/A$/B/;\n echo 0 0000000000000000000000000000000000000000\tA) \\\n | git-update-index --index-info\n\nIOW:\n 1. move working tree A to B\n 2. create staged entry B, same as staged entry A\n 3. remove staged entry A\n\n> Hmm, that's an interesting point. Are you talking about situations in\n> which your changes after (1) leave the program in an uncompilable state?\n\nNo, I meant more that the state you have staged will never have actually\nexisted in your working tree, so you could not possibly have tested it.\nHowever, it may be that the changes you are trying to avoid staging are\ntrivial, and you're willing to accept that. And git shouldn't stand in\nyour way.\n\nAnd it sounds like you don't necessarily want to make a _commit_ out of\nthis, you just want to keep working and not have git-mv munge your\nstaged state.\n\n> I don't really see why you're analyzing the situations in which this\n> would be used. I think it should be obvious from my descriptions of my\n\nBecause I was having trouble understanding what Michael was trying to\naccomplish with his \"here are two methods, and one is better\" since they\nseemed to do different things. But that is perhaps my fault for joining\nthe thread in the middle. I may have simply caused more confusion by\ngetting involved. :)\n\nNow I think I understand exactly what you're trying to accomplish,\nand I agree that it makes sense. Shawn is right that \"git-mv --cached\"\ndoesn't do what you want, since to be consistent with other tools it\nwouldn't touch the working tree (though I wonder if you would be\nsatisfied with \"git-mv --cached A B; mv A B\"). I think at this point the\nbest way forward is to produce a patch and try to solicit comments (in\nparticular, which behaviors should be supported (current, --cached, or\nwhat you are proposing) and which should be the default).\n\n> But... that's not even the point I was going to make. I think the\n> questions you should be asking are things like \"Does this fit with the\n> overall architecture?\", \"Does this or doesn't this provide power and\n> flexibility to the user?\", etc. Is git being made for \"the 80%\" that use\n\nThere seems to be a strong sentiment among the various gits that you\nshouldn't build in flexibility for the sake of flexibility if there's no\ngood use for it. I tend to be less of that sentiment than some others\nhere, but I think when proposing a feature it is still worth saying \"and\nhere's why it's useful.\"\n\n> Sorry if anything I've said here sounded confrontational; that was not\n> not my intent at all. I'm just raising some points I think are\n> important. I don't want any flame wars...\n\nI think you stated your position fine. And we've had enough flame wars\naround here lately to last us a while.\n\n-Peff\n"},{"id":"56660","messageId":"20071020063014.GU14735@spearce.org","threadId":"10361","inReplyTo":"1192859758.13347.148.camel@g4mdd.entnet","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-20T06:30:14Z","receivedAt":"2007-10-20T06:30:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Ari Entlich wrote:\n> On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:\n> > --index is used in Git for places were we update *both* the index\n> > and the working directory (git-apply --index). So actually I should\n> > have suggested \"git-mv --index\". Whoops.\n> \n> Alright then, I don't know about that particular convention. If this\n> behavior can't be made default, git mv --index should activate it? I\n> there anything else that might be more descriptive?\n\nThat's always the hard part. I actually think the current behavior\nshould be called --index as it does not only the working tree\nupdate but also stages the whole file into the index, which is what\ngit-apply --index does.\n\nWhat about just -u for \"keep unstaged\"?\n \n> Might it be possible to simply get the struct cache_entry for the file\n> which we want to rename, change its name property (would this involve\n> xreallocing it?), and change the ce_namelen field of ce_flags?\n\nYes.\n \n> In any case, I think the ce_flags would need to be changed to reflect\n> the new name length. Also, it seems that the old ce_mtime, ce_dev,\n> ce_ino, ce_uid, ce_gid, and ce_size could be used too... ce_ctime would\n> need to be updated...\n\nCorrect. The ce_size shouldn't change as a result of the rename but\nthe other properties of a struct stat may. I'd like to think that\nce_uid and ce_gid wouldn't change as a result of a rename but there's\nprobably some bastard filesystem somewhere that that won't hold true.\n\nJust call fill_stat_cache_info() on your xrealloc'd entry and pass\nit a stat buffer for the file after the rename and you should be\ncovered here.\n\n> > I'm sure Junio could probably give you a better starting point\n> > than I can, as he's more familiar with this sort of code, but that\n> > should still get you looking in the right direction and maybe get\n> > a working implementation together that you can share for discussion.\n> \n> Yeah, I'd appreciate any help I can get. The people on #git were\n> invoking the \"the code is the documentation\" ideology. :)\n\nIt really is in this case. You are talking about hacking on\nGit itself. For the most part we believe in \"the code is the\ndocumentation\" for the guts as otherwise the documentation gets\nout of sync with the code when the code changes. User level docs\nare different as the user interface needs to stay stable.\n\n> So... Ping Junio...? I actually haven't seen any messages from him since\n> I subscribed to this list (I've only gotten about 300 messages so far,\n> but I'd expect to see a lot from him as he's the maintainer...). Is he\n> away at the moment or something?\n\nYes. We run like 100 messages a day so I guess you've only joined\nin the past few days. Welcome to the list. :-)\n\nJunio has been away for about 2 weeks now. He's basically off\non leave as he needed some time to take care of some things.\nI'm filling in for him until he returns.\n\n-- \nShawn.\n"},{"id":"56662","messageId":"20071020063428.GC30388@coredump.intra.peff.net","threadId":"10361","inReplyTo":"1192859758.13347.148.camel@g4mdd.entnet","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T06:34:28Z","receivedAt":"2007-10-20T06:34:28Z","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:58AM -0400, Ari Entlich wrote:\n\n> Might it be possible to simply get the struct cache_entry for the file\n> which we want to rename, change its name property (would this involve\n> xreallocing it?), and change the ce_namelen field of ce_flags?\n\nThe sort order of entries in the cache is important, so you would have\nto move the entry, as well.\n\n-Peff\n"},{"id":"56663","messageId":"FF5A82CA-8AE3-4E1C-872D-26D938933E1B@MIT.EDU","threadId":"10361","inReplyTo":"20071020062400.GA30388@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-20T06:34:49Z","receivedAt":"2007-10-20T06:34:49Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 20 Oct 2007, at 2:24:00 AM, Jeff King wrote:\n\n> Because I was having trouble understanding what Michael was trying to\n> accomplish with his \"here are two methods, and one is better\" since \n> they\n> seemed to do different things. But that is perhaps my fault for \n> joining\n> the thread in the middle. I may have simply caused more confusion by\n> getting involved. :)\n\nThe first method is wrong, because I wasn't considering the fact that\nhe may have already staged something.\n\nBecause I thought both methods achieve the same result, I called the \nlatter\n\"better\", because it is more efficient.\n\nMichael Witten\nmfwitten\n"},{"id":"56664","messageId":"20071020063607.GA30572@coredump.intra.peff.net","threadId":"10361","inReplyTo":"FF5A82CA-8AE3-4E1C-872D-26D938933E1B@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T06:36:07Z","receivedAt":"2007-10-20T06:36:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2007 at 02:34:49AM -0400, Michael Witten wrote:\n\n> The first method is wrong, because I wasn't considering the fact that\n> he may have already staged something.\n\nYes, I also didn't consider that, which is what led me to wonder what\nhis use case could possibly be. And thus we were both confused.\n\n-Peff\n"},{"id":"56665","messageId":"20071020063628.GV14735@spearce.org","threadId":"10361","inReplyTo":"20071020062400.GA30388@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-20T06:36:28Z","receivedAt":"2007-10-20T06:36:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> No, I meant more that the state you have staged will never have actually\n> existed in your working tree, so you could not possibly have tested it.\n> However, it may be that the changes you are trying to avoid staging are\n> trivial, and you're willing to accept that. And git shouldn't stand in\n> your way.\n> \n> And it sounds like you don't necessarily want to make a _commit_ out of\n> this, you just want to keep working and not have git-mv munge your\n> staged state.\n\nYea, I want the same thing. :-)\n\nAnd not because I commit things that weren't tested. Its because\nI do mini code reviews for small hunks at a time. I stage things\nI have looked at, and keep things I'm still unsure about unstaged.\nBut before I commit I make sure my `git diff` output is empty,\nso I know that any tests I do now will match what I have when I\nrun git-commit.\n\nSo lets say I make a change in my Makefile that changes the name\nof a source file to be more descriptive of that file's contents.\nI've reviewed the Makefile change *and* done the file rename,\nbut I'm still not done reviewing the stuff in the file. (Yea,\nmaybe that should be two different commits, but maybe not, lets\nnot get into that as it depends very much on context.)\n\nToday I move the file, then unstage the hunks I'm not sure about,\nthen go back and restage them. Annoying. It really disrupts\nmy workflow.\n\nThe killer feature in Git for me is the index. That sucker saves\nme on a daily basis as it lets me organize \"this i'm happy with,\nthis i'm not\" while I'm in the middle of making a single new commit.\nToday git-mv robs me of it.\n \n-- \nShawn.\n"},{"id":"56666","messageId":"20071020064003.GA30605@coredump.intra.peff.net","threadId":"10361","inReplyTo":"20071020063628.GV14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-20T06:40:03Z","receivedAt":"2007-10-20T06:40:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 20, 2007 at 02:36:28AM -0400, Shawn O. Pearce wrote:\n\n> So lets say I make a change in my Makefile that changes the name\n> of a source file to be more descriptive of that file's contents.\n> I've reviewed the Makefile change *and* done the file rename,\n> but I'm still not done reviewing the stuff in the file. (Yea,\n> maybe that should be two different commits, but maybe not, lets\n> not get into that as it depends very much on context.)\n\nRight. So the exact state you have in your index never actually existed\nin your working tree. But that's OK if:\n - the changes are trivial and obviously correct\n - you're not actually planning on _committing_ that, you just want to\n build the commit using the index\nAnd in those cases, git-stash is either, respectively, overkill or\ntotally useless.\n\nPlease ignore everything I said on this subject before today...I\nobviously hadn't figured out what was going on.\n\n-Peff\n"},{"id":"56669","messageId":"8D972813-2D7F-4D6A-958F-B76E947E7BC3@MIT.EDU","threadId":"10361","inReplyTo":"20071020063628.GV14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-20T06:45:05Z","receivedAt":"2007-10-20T06:45:05Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 20 Oct 2007, at 2:36:28 AM, Shawn O. Pearce wrote:\n\n> Today I move the file, then unstage the hunks I'm not sure about,\n> then go back and restage them. Annoying. It really disrupts\n> my workflow.\n\nI know it's against policy, but the proposed change should be set\nas the default at some point, in my opinion.\n\nPerhaps when the -u flagged is not used, there can be a warning that\nstates -u will become the default at a certain time.\n\nIn fact, -u speaks \"update\" to me, and I would expect it to signal\nthe current behavior.\n\nI have a feeling that my suggestion will not go far,\nbut I also think that backwards compatibility can\noverstay its welcome.\n"},{"id":"56672","messageId":"20071020070249.GX14735@spearce.org","threadId":"10361","inReplyTo":"8D972813-2D7F-4D6A-958F-B76E947E7BC3@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-20T07:02:49Z","receivedAt":"2007-10-20T07:02:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael Witten wrote:\n> \n> On 20 Oct 2007, at 2:36:28 AM, Shawn O. Pearce wrote:\n> \n> >Today I move the file, then unstage the hunks I'm not sure about,\n> >then go back and restage them. Annoying. It really disrupts\n> >my workflow.\n> \n> I know it's against policy, but the proposed change should be set\n> as the default at some point, in my opinion.\n\nIts not so much policy as a timing issue.\n\nGit 1.5.4 shouldn't have major distruptions to end-users in terms\nof changing existing behavior to be different than in 1.5.3.\nEspecially default behavior.\n\nGit 1.6.0 we're a little bit more willing to change default\nbehavior as it is a full major release. This is probably quite a\nbit off still, unless we started to accumulate a lot of really good\nchanges that required breaking something in the user interface.\nThat's what happened with the 1.4.4 series vs. 1.5.0. Right now\nI don't see that happening anytime soon.\n\n> I have a feeling that my suggestion will not go far,\n> but I also think that backwards compatibility can\n> overstay its welcome.\n\nI agree.\n\n-- \nShawn.\n"},{"id":"56677","messageId":"20071020074654.GA3497@glandium.org","threadId":"10361","inReplyTo":"20071020063014.GU14735@spearce.org","subject":"Re: Proposed git mv behavioral change","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-20T07:46:54Z","receivedAt":"2007-10-20T07:46:54Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Oct 20, 2007 at 02:30:14AM -0400, Shawn O. Pearce wrote:\n> Ari Entlich wrote:\n> > On Thu, 2007-10-18 at 21:54 -0400, Shawn O. Pearce wrote:\n> > > --index is used in Git for places were we update *both* the index\n> > > and the working directory (git-apply --index). So actually I should\n> > > have suggested \"git-mv --index\". Whoops.\n> > \n> > Alright then, I don't know about that particular convention. If this\n> > behavior can't be made default, git mv --index should activate it? I\n> > there anything else that might be more descriptive?\n> \n> That's always the hard part. I actually think the current behavior\n> should be called --index as it does not only the working tree\n> update but also stages the whole file into the index, which is what\n> git-apply --index does.\n> \n> What about just -u for \"keep unstaged\"?\n\nWhy not --staged ? It would be more meaningful than the --cached in some\nother commands.\n\nMike\n"},{"id":"56692","messageId":"87ACA689-CBBD-4E6D-9BAD-B3BBA8391DB9@wincent.com","threadId":"10361","inReplyTo":"8D972813-2D7F-4D6A-958F-B76E947E7BC3@MIT.EDU","subject":"Re: Proposed git mv behavioral change","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-20T11:15:19Z","receivedAt":"2007-10-20T11:15:19Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 20/10/2007, a las 8:45, Michael Witten escribió:\n\n> On 20 Oct 2007, at 2:36:28 AM, Shawn O. Pearce wrote:\n>\n>> Today I move the file, then unstage the hunks I'm not sure about,\n>> then go back and restage them. Annoying. It really disrupts\n>> my workflow.\n>\n> I know it's against policy, but the proposed change should be set\n> as the default at some point, in my opinion.\n\nI think the issue here is that git-mv as it is currently implemented \nreally conflates two things:\n\n1. Renaming a file in the traditional \"mv\" sense\n2. Staging the entire contents of the file in the index, ready or not\n\nSo it's kind of like the command were called git-mv-and-add or git- \nrename-and-add. And given that the index as a staging area is such a \ncentral content in Git, users often want to have more control over \nwhat gets added to the index than that; ie. \"I really just wanted to \nrename the file, and leave the staging of modifications to the \ncontent up to me\".\n\nCheers,\nWincent\n"},{"id":"56877","messageId":"20071022140015.GA1992@diana.vm.bytemark.co.uk","threadId":"10361","inReplyTo":"20071020064003.GA30605@coredump.intra.peff.net","subject":"Re: Proposed git mv behavioral change","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-22T14:00:15Z","receivedAt":"2007-10-22T14:00:15Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-20 02:40:03 -0400, Jeff King wrote:\n\n> Right. So the exact state you have in your index never actually\n> existed in your working tree. But that's OK if:\n> - the changes are trivial and obviously correct\n> - you're not actually planning on _committing_ that, you just want\n> to build the commit using the index\n\nOr\n\n - you plan to revisit the commit at a later time and verify that\n it's OK\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"56878","messageId":"20071022140841.GB1992@diana.vm.bytemark.co.uk","threadId":"10361","inReplyTo":"87ACA689-CBBD-4E6D-9BAD-B3BBA8391DB9@wincent.com","subject":"Re: Proposed git mv behavioral change","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-10-22T14:08:41Z","receivedAt":"2007-10-22T14:08:41Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-10-20 13:15:19 +0200, Wincent Colaiuta wrote:\n\n> I think the issue here is that git-mv as it is currently implemented\n> really conflates two things:\n>\n> 1. Renaming a file in the traditional \"mv\" sense\n> 2. Staging the entire contents of the file in the index, ready or not\n>\n> So it's kind of like the command were called git-mv-and-add or git-\n> rename-and-add. And given that the index as a staging area is such a\n> central content in Git, users often want to have more control over\n> what gets added to the index than that; ie. \"I really just wanted to\n> rename the file, and leave the staging of modifications to the\n> content up to me\".\n\nI've come to that conclusion too while reading this thread. It would\nmake more sense for git-mv to, as others have already suggested, move\nthe file in the worktree and move the file in the index but _not_ add\nworkdir updates to the index. git-mv --cached would do only the index,\nand not touch the worktree.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}