{"thread":{"id":"29306","subject":"Aborting \"git commit --interactive\" discards updates to index (was: Re: [ANNOUNCE] Git 1.7.6)","startedAt":"2012-01-06T16:37:14Z","lastAt":"2012-01-09T00:41:39Z","messageCount":4,"participants":["demerphq","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182029","messageId":"CANgJU+X+qLe3Aqy_ZpoSDKMuf=8=OxVvpkt0tGmSi=KVgti3HQ@mail.gmail.com","threadId":"29306","inReplyTo":null,"subject":"Aborting \"git commit --interactive\" discards updates to index (was: Re: [ANNOUNCE] Git 1.7.6)","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-01-06T16:37:14Z","receivedAt":"2012-01-06T16:37:14Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 27 June 2011 17:59, Junio C Hamano wrote:\n> The latest feature release Git 1.7.6 is available at the usual\n> places:\n>\n>  http://www.kernel.org/pub/software/scm/git/\n[snip]\n>  * Aborting \"git commit --interactive\" discards updates to the index\n>   made during the interactive session.\n\nHi, I am wondering why this change was made?\n\nI can sort of understand if people do CTL-C during an interactive\ncommit that throwing the results away might be useful (although I\ndon't see why personally), but what I don't understand at all is why\nit happens when the \"add --interactive\" is completed properly, but the\nuser decided not to actually commit. For me and a number of colleagues\nthe normal reason we exit the commit part (that is exit the editor\nwithout modifying the commit message) is because we realize we forgot\nsomething, such as adding a new file, and want to exit out and re-add\nit. I am writing this after spending about 45 minutes showing a\ncolleague how to use git commit --interactive, when we realized that\nwe had forgotten to add a file. Needless to say he wasn't too happy\nabout losing 45 minutes work and having to redo it.\n\nThe new behavior potentially means that a lot of work (such as via the\n'e' option) is instantly discarded. I don't understand why this is\nperceived to be sensible behavior -- I thought the default policy for\ngit would be to not lose work!\n\nI would really like an git config option to revert to the previous\nbehavior of not throwing away what I staged, or even better have git\ncommit --interactive ask me what I want to do, after all, it is an\ninteractive process so it seems reasonable it asks before it does\nsomething like throw away work.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"182057","messageId":"7vvcoogkw8.fsf@alter.siamese.dyndns.org","threadId":"29306","inReplyTo":"CANgJU+X+qLe3Aqy_ZpoSDKMuf=8=OxVvpkt0tGmSi=KVgti3HQ@mail.gmail.com","subject":"Re: Aborting \"git commit --interactive\" discards updates to index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-07T05:08:07Z","receivedAt":"2012-01-07T05:08:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> On 27 June 2011 17:59, Junio C Hamano wrote:\n>> The latest feature release Git 1.7.6 is available at the usual\n>> places:\n>>\n>> http://www.kernel.org/pub/software/scm/git/\n> [snip]\n>> * Aborting \"git commit --interactive\" discards updates to the index\n>> made during the interactive session.\n>\n> Hi, I am wondering why this change was made?\n\nI wasn't directly involved in this particular part of the design of what\nshould happen to the index when a commit is aborted, so I would be a bad\nperson to give you the first answer, but let's try.\n\nIf a \"commit\" session is aborted, it is logical to revert whatever has\nbeen done inside that session as a single logical unit, so I do not\nparticularly find the current behaviour so confusing. It might even make\nmore sense if we update \"commit -i\" and \"commit -a\" to also revert the\nindex modification when the command is aborted for consistency.\n\nYou are welcome to rehash the age old discussion, though. Personally I do\nnot care very deeply either way. I would never use \"commit --interactive\"\nmyself, and I would not encourage others to use it, either, even if we do\nnot worry about the behaviour when a commit is aborted.\n\nOne thread of interest (there are others, as this change was rerolled at\nleast a few times) may be\n\n http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173035\n\nHaving said all that,...\n\n> .... I am writing this after spending about 45 minutes showing a\n> colleague how to use git commit --interactive, when we realized that\n> we had forgotten to add a file....\n\n... if your partial commit is so complex that you need to spend 45 minutes\nto sift what to be commited and what to be left out, you are much better\noff to run \"git add -i\" to prepare the index, \"git stash save -k\" to check\nout what is to be committed (and stash away what are to be left out) so\nthat you can make sure what you are committing is what you thought are\ncommitting (by asking \"git diff\" and \"make test\" for example), and after\nconvincing yourself that you made a good state in the index, make a commit\nwith \"git commit\" (without any other arguments) and conclude it with \"git\nstash pop\" to recover the changes that you decided to leave out.\n\n\"commit --interactive\" robs me from that crucial \"verification\" step, and\nthat is why I wouldn't be a user or an advocate of this \"misfeature\".\n\nBy the way, why did you draw Ævar into this discussion? I do not think he\nwas involved in any way with the design or implementation of this command.\n"},{"id":"182069","messageId":"CANgJU+WGEBMMQzsGyQSnMBK3Q8Z2XZdbDx4nr-tB-s0uYEU9CQ@mail.gmail.com","threadId":"29306","inReplyTo":"7vvcoogkw8.fsf@alter.siamese.dyndns.org","subject":"Re: Aborting \"git commit --interactive\" discards updates to index","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2012-01-07T14:16:54Z","receivedAt":"2012-01-07T14:16:54Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 7 January 2012 06:08, Junio C Hamano wrote:\n> demerphq writes:\n>\n>> On 27 June 2011 17:59, Junio C Hamano wrote:\n>>> The latest feature release Git 1.7.6 is available at the usual\n>>> places:\n>>>\n>>>  http://www.kernel.org/pub/software/scm/git/\n>> [snip]\n>>>  * Aborting \"git commit --interactive\" discards updates to the index\n>>>   made during the interactive session.\n>>\n>> Hi, I am wondering why this change was made?\n>\n> I wasn't directly involved in this particular part of the design of what\n> should happen to the index when a commit is aborted, so I would be a bad\n> person to give you the first answer, but let's try.\n>\n> If a \"commit\" session is aborted, it is logical to revert whatever has\n> been done inside that session as a single logical unit, so I do not\n> particularly find the current behaviour so confusing. It might even make\n> more sense if we update \"commit -i\" and \"commit -a\" to also revert the\n> index modification when the command is aborted for consistency.\n>\n> You are welcome to rehash the age old discussion, though. Personally I do\n> not care very deeply either way. I would never use \"commit --interactive\"\n> myself, and I would not encourage others to use it, either, even if we do\n> not worry about the behaviour when a commit is aborted.\n\nIf I were to provide a patch to make this behavior configurable would\nyou have any objections? I personally much prefer the old behaviour. I\nwant it to leave the stuff in my index.\n\n>\n> One thread of interest (there are others, as this change was rerolled at\n> least a few times) may be\n>\n>    http://thread.gmane.org/gmane.comp.version-control.git/173033/focus=173035\n\nThanks.\n\n> Having said all that,...\n>\n>> .... I am writing this after spending about 45 minutes showing a\n>> colleague how to use git commit --interactive, when we realized that\n>> we had forgotten to add a file....\n>\n> ... if your partial commit is so complex that you need to spend 45 minutes\n> to sift what to be commited and what to be left out, you are much better\n\nI was showing a colleague how to use the features it provides on a\nlarge patch where the committer wanted to keep various bits and not\nkeep others.\n\n> off to run \"git add -i\" to prepare the index, \"git stash save -k\" to check\n> out what is to be committed (and stash away what are to be left out) so\n> that you can make sure what you are committing is what you thought are\n> committing (by asking \"git diff\" and \"make test\" for example), and after\n\nIsnt this what the diff option in commit interactive is for?\nPersonally I tend to review patches in detail before I push them, not\nnecessarily before I commit them.\n\n> convincing yourself that you made a good state in the index, make a commit\n> with \"git commit\" (without any other arguments) and conclude it with \"git\n> stash pop\" to recover the changes that you decided to leave out.\n\nI personally have never had an issue with git commit --interactive so\nthis procedure seems really convoluted to me, and a lot harder to\nteach to a colleague than \"use git commit --interactive\". Is there a\nreal problem it solves?\n\n> \"commit --interactive\" robs me from that crucial \"verification\" step, and\n> that is why I wouldn't be a user or an advocate of this \"misfeature\".\n\nI understand. But that is a workflow directed to statically testable\nlibrary code. Our workflow doesn't really depend on a \"make test\"\nphase. Also, if I calling git commit --interactive (or git add -i),\nthen I am as confident my code works as I can be, and the reason I am\ndoing an interactive step is for instance to edit out debug lines, or\nseparate out whitespace changes from code changes, or to break my\nchange set into several logical groups.\n\n> By the way, why did you draw Ævar into this discussion? I do not think he\n> was involved in any way with the design or implementation of this command.\n\nHe is a git hacker, and is a friend and colleague. We both work for a\nlargish dotcom which uses git as our primary version control and we\nhave collaborated on a tool I wrote to use git to manage our rollout\nprocesses. So when something git comes up it is natural to me to CC\nhim.\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"182144","messageId":"7v62glg118.fsf@alter.siamese.dyndns.org","threadId":"29306","inReplyTo":"CANgJU+WGEBMMQzsGyQSnMBK3Q8Z2XZdbDx4nr-tB-s0uYEU9CQ@mail.gmail.com","subject":"Re: Aborting \"git commit --interactive\" discards updates to index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-09T00:41:39Z","receivedAt":"2012-01-09T00:41:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> On 7 January 2012 06:08, Junio C Hamano wrote:\n> ...\n>> You are welcome to rehash the age old discussion, though. Personally I do\n>> not care very deeply either way. I would never use \"commit --interactive\"\n>> myself, and I would not encourage others to use it, either, even if we do\n>> not worry about the behaviour when a commit is aborted.\n>\n> If I were to provide a patch to make this behavior configurable would\n> you have any objections?\n\nYou are welcome to rehash the discussion.\n\nI am not a dictator and will listen to other people on the list for their\nopinions, and I cannot say if such a patch will be accepted or not without\nseeing how well it is done.\n\n>> ... off to run \"git add -i\" to prepare the index, \"git stash save -k\" to check\n>> out what is to be committed (and stash away what are to be left out) so\n>> that you can make sure what you are committing is what you thought are\n>> committing (by asking \"git diff\" and \"make test\" for example), and after\n>\n> Isnt this what the diff option in commit interactive is for?\n\nNot at all.\n\nThat is to help the user incrementally in the process and not a\nreplacement for the final eyeballing of the result.\n\nNeither the patch shown in \"commit -v\", whose primary purpose is to aid\nthe user to write a better log message.\n"}]}