{"thread":{"id":"22494","subject":"[BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","startedAt":"2010-02-02T20:07:17Z","lastAt":"2010-02-03T19:54:04Z","messageCount":45,"participants":["Eugene Sajine","Jacob Helwig","Avery Pennarun","Wincent Colaiuta","Erik Faye-Lund","Johannes Schindelin","Junio C Hamano","SZEDER Gábor","Larry D'Anna","Matthieu Moy","Jeff King","Paolo Bonzini","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133383","messageId":"76c5b8581002021207y3eccdc19i9a4abcc3d04315f0@mail.gmail.com","threadId":"22494","inReplyTo":null,"subject":"[BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T20:07:17Z","receivedAt":"2010-02-02T20:07:17Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"Hi,\n\nIt seems to me it is a bug:\n\nWhen git commit --amend is executed it fires up vi so i can change the\ncommit message. If I have something staged, then when I'm exiting vi\nusing :q (without doing/writing any changes), it still commits\neverything staged with old message.\n\nI believe it should actually abort amending and return to the state\nbefore the \"git commit --amend\" was issued.\n\nThanks,\nEugene\n"},{"id":"133384","messageId":"8c9a061002021214j673afbc8vfa5d941fba518648@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021207y3eccdc19i9a4abcc3d04315f0@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-02-02T20:14:30Z","receivedAt":"2010-02-02T20:14:30Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Tue, Feb 2, 2010 at 12:07, Eugene Sajine wrote:\n> Hi,\n>\n> It seems to me it is a bug:\n>\n> When git commit --amend is executed it fires up vi so i can change the\n> commit message. If I have something staged, then when I'm exiting vi\n> using :q (without doing/writing any changes), it still commits\n> everything staged with old message.\n>\n> I believe it should actually abort amending and return to the state\n> before the \"git commit --amend\" was issued.\n>\n> Thanks,\n> Eugene\n>\n\nI don't think this is actually the right way to go. A _very_ common\nuse case for \"commit --amend\" is to add things to the previous commit,\nwithout changing the commit message at all. Yes, you can avoid having\nto fire up the editor at all in this case, but it's still a perfectly\nvalid thing to want to do.\n\nIf you want to abort amending, and return to the state before the \"git\ncommit --amend\", you can remove all non-comment lines (IE: write out\nan \"empty\" commit message), or have your editor exit with a non-zero\nexit code (Use \":cquit\").\n\nThe comment block that comes up in your editor mentions this first\nmethod, explicitly. \"..., and an empty message aborts the commit.\"\n\n-Jacob\n"},{"id":"133387","messageId":"32541b131002021227o1ec9f369w6096e85382857b8a@mail.gmail.com","threadId":"22494","inReplyTo":"8c9a061002021214j673afbc8vfa5d941fba518648@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T20:27:12Z","receivedAt":"2010-02-02T20:27:12Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig wrote:\n> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine wrote:\n>> When git commit --amend is executed it fires up vi so i can change the\n>> commit message. If I have something staged, then when I'm exiting vi\n>> using :q (without doing/writing any changes), it still commits\n>> everything staged with old message.\n>>\n>> I believe it should actually abort amending and return to the state\n>> before the \"git commit --amend\" was issued.\n>\n> I don't think this is actually the right way to go.  A _very_ common\n> use case for \"commit --amend\" is to add things to the previous commit,\n> without changing the commit message at all.  Yes, you can avoid having\n> to fire up the editor at all in this case, but it's still a perfectly\n> valid thing to want to do.\n\nI agree and I do this all the time. However, I've also done it\naccidentally before I learned the \"remove the commit message and save\"\ntrick.\n\nPerhaps what's really missing is more documentation of how to\n\"unamend\" if you change your mind :) I happen to know about \"git\nreset HEAD@{1}\" but it's not terribly obvious.\n\nAvery\n"},{"id":"133389","messageId":"76c5b8581002021247j6df8f609ld9e5d87a060a5423@mail.gmail.com","threadId":"22494","inReplyTo":"32541b131002021227o1ec9f369w6096e85382857b8a@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T20:47:45Z","receivedAt":"2010-02-02T20:47:45Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Tue, Feb 2, 2010 at 3:27 PM, Avery Pennarun wrote:\n> On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig wrote:\n>> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine wrote:\n>>> When git commit --amend is executed it fires up vi so i can change the\n>>> commit message. If I have something staged, then when I'm exiting vi\n>>> using :q (without doing/writing any changes), it still commits\n>>> everything staged with old message.\n>>>\n>>> I believe it should actually abort amending and return to the state\n>>> before the \"git commit --amend\" was issued.\n>>\n>> I don't think this is actually the right way to go.  A _very_ common\n>> use case for \"commit --amend\" is to add things to the previous commit,\n>> without changing the commit message at all.  Yes, you can avoid having\n>> to fire up the editor at all in this case, but it's still a perfectly\n>> valid thing to want to do.\n>\n> I agree and I do this all the time. However, I've also done it\n> accidentally before I learned the \"remove the commit message and save\"\n> trick.\n>\n> Perhaps what's really missing is more documentation of how to\n> \"unamend\" if you change your mind :)  I happen to know about \"git\n> reset HEAD@{1}\" but it's not terribly obvious.\n>\n> Avery\n>\n\nWell, i understand this logic but it seems to me that the issue is a\nlittle bit deeper than that.\nI just realized that the \"rebase -i\" is doing the same thing.\n\nIf you're just exiting the vi using :q without writing changes it will\nperform rebase! I'm 100% sure it is not OK.\n\nSo, it seems that it will do that every time it has some\n*prepopulated* message in the editor, so it doesn't understand when\nchanges are written and when they are not.\n\nI believe all those actions should be treated exactly the same way as\nthe commit itself. If I'm writing/saving changes - it is good to go.\nIf not - abort.\nI.e. the message can be prepopulated in the editor, but it should be\nthe same state as when you create a new message for commit, i.e. git\nshould not know anything about that message.\n\nThanks,\nEugene\n"},{"id":"133394","messageId":"394FB581-C9B9-40AB-AFB6-39B68ED5BEAD@wincent.com","threadId":"22494","inReplyTo":"76c5b8581002021247j6df8f609ld9e5d87a060a5423@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-02-02T20:58:45Z","receivedAt":"2010-02-02T20:58:45Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 02/02/2010, a las 21:47, Eugene Sajine escribió:\n\n> On Tue, Feb 2, 2010 at 3:27 PM, Avery Pennarun \n> wrote:\n>> On Tue, Feb 2, 2010 at 3:14 PM, Jacob Helwig \n>> wrote:\n>>> On Tue, Feb 2, 2010 at 12:07, Eugene Sajine \n>>> wrote:\n>>>> When git commit --amend is executed it fires up vi so i can \n>>>> change the\n>>>> commit message. If I have something staged, then when I'm exiting \n>>>> vi\n>>>> using :q (without doing/writing any changes), it still commits\n>>>> everything staged with old message.\n>>>>\n>>>> I believe it should actually abort amending and return to the state\n>>>> before the \"git commit --amend\" was issued.\n>>>\n>>> I don't think this is actually the right way to go. A _very_ common\n>>> use case for \"commit --amend\" is to add things to the previous \n>>> commit,\n>>> without changing the commit message at all. Yes, you can avoid \n>>> having\n>>> to fire up the editor at all in this case, but it's still a \n>>> perfectly\n>>> valid thing to want to do.\n>>\n>> I agree and I do this all the time. However, I've also done it\n>> accidentally before I learned the \"remove the commit message and \n>> save\"\n>> trick.\n>>\n>> Perhaps what's really missing is more documentation of how to\n>> \"unamend\" if you change your mind :) I happen to know about \"git\n>> reset HEAD@{1}\" but it's not terribly obvious.\n>>\n>> Avery\n>>\n>\n> Well, i understand this logic but it seems to me that the issue is a\n> little bit deeper than that.\n> I just realized that the \"rebase -i\" is doing the same thing.\n>\n> If you're just exiting the vi using :q without writing changes it will\n> perform rebase! I'm 100% sure it is not OK.\n\nAs has already been pointed out, an extremely common workflow for \"git \ncommit --amend\" is to include additional changes that were \naccidentally overlooked in the initial commit, and no changes are \nmade to the commit message.\n\nChanging the behavior would break that perfectly reasonable, widely- \npractised workflow, and _that_ would be 100% not ok.\n\nLucky for you, you've already been provided with two means of aborting \n(empty commit message, and non-zero editor exit), so you might as well \nstart getting used to them.\n\nWincent\n"},{"id":"133393","messageId":"32541b131002021318q4e25967dp8ed001b0fb92b2ae@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021247j6df8f609ld9e5d87a060a5423@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T21:18:06Z","receivedAt":"2010-02-02T21:18:06Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 3:47 PM, Eugene Sajine wrote:\n> If you're just exiting the vi using :q without writing changes it will\n> perform rebase! I'm 100% sure it is not OK.\n>\n> So, it seems that it will do that every time it has some\n> *prepopulated* message in the editor, so it doesn't understand when\n> changes are written and when they are not.\n>\n> I believe all those actions should be treated exactly the same way as\n> the commit itself. If I'm writing/saving changes - it is good to go.\n> If not - abort.\n\nIt might be sort of neat to check the mtime of the commit message file\nbefore and after launching the editor; then if you want, you could\nforce-save the file even without any changes, and git would know that\nyou want it changed.\n\nNot sure I would like that behaviour better than the current way,\nactually, but it's an idea.\n\nAvery\n"},{"id":"133399","messageId":"76c5b8581002021356m52bb1817k9a4a29da0d4b681d@mail.gmail.com","threadId":"22494","inReplyTo":"394FB581-C9B9-40AB-AFB6-39B68ED5BEAD@wincent.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T21:56:30Z","receivedAt":"2010-02-02T21:56:30Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> As has already been pointed out, an extremely common workflow for \"git\n> commit --amend\" is to include additional changes that were accidentally\n> overlooked  in the initial commit, and no changes are made to the commit\n> message.\n>\n> Changing the behavior would break that perfectly reasonable,\n> widely-practised workflow, and _that_ would be 100% not ok.\n\nI'm not against that workflow - I'm not forcing anybody to change the\ncommit message. The thing I'm talking about is roughly that it should\nNOT treat the result of command \":q\" the same way as the command\n\":wq\".\n\nFor example IF there is a variable somewhere where message is stored:\nFor new commit message it is NULL and when commit is ready it is set\nup to \"message\". We check If it is not empty and not NULL (:wq\nexecuted), then we can commit.\nFor \"prepopulated\" messages this variable can be is set to \"message\"\nfrom the beginning, so it doesn't matter if you're writing changes or\nnot the check will always be true, so we can commit.\nIf the implementation would be like this, then I would propose to\nclean up this variable after the prepopulated message is populated, so\nit won't use it blindly, but only after you're overwriting the message\n(even if the message is not changed).\n"},{"id":"133403","messageId":"40aa078e1002021403x49920df9x3eca13207ce3e9f9@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021356m52bb1817k9a4a29da0d4b681d@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-02T22:03:22Z","receivedAt":"2010-02-02T22:03:22Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Feb 2, 2010 at 10:56 PM, Eugene Sajine wrote:\n>>\n>> As has already been pointed out, an extremely common workflow for \"git\n>> commit --amend\" is to include additional changes that were accidentally\n>> overlooked  in the initial commit, and no changes are made to the commit\n>> message.\n>>\n>> Changing the behavior would break that perfectly reasonable,\n>> widely-practised workflow, and _that_ would be 100% not ok.\n>\n> I'm not against that workflow - I'm not forcing anybody to change the\n> commit message. The thing I'm talking about is roughly that it should\n> NOT treat the result of command \":q\" the same way as the command\n> \":wq\".\n>\n\nQuite a lot of text-editors on prevents a user from saving when the\nbuffer is unchanged, so I don't think this would actually work. Keep\nin mind that vi is not the only editor one can use to edit commit\nmessages.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"133407","messageId":"77153A83-158D-4D36-A622-7AA3947C7D52@wincent.com","threadId":"22494","inReplyTo":"76c5b8581002021356m52bb1817k9a4a29da0d4b681d@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-02-02T22:06:29Z","receivedAt":"2010-02-02T22:06:29Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 02/02/2010, a las 22:56, Eugene Sajine escribió:\n\n>>\n>> As has already been pointed out, an extremely common workflow for \n>> \"git\n>> commit --amend\" is to include additional changes that were \n>> accidentally\n>> overlooked in the initial commit, and no changes are made to the \n>> commit\n>> message.\n>>\n>> Changing the behavior would break that perfectly reasonable,\n>> widely-practised workflow, and _that_ would be 100% not ok.\n>\n> I'm not against that workflow - I'm not forcing anybody to change the\n> commit message. The thing I'm talking about is roughly that it should\n> NOT treat the result of command \":q\" the same way as the command\n> \":wq\".\n\nWhy should Git care about how you exited from your EDITOR? All it \nshould care about is the contents of the commit message, and the exit \ncode of the editor.\n\n> For example IF there is a variable somewhere where message is stored:\n> For new commit message it is NULL and when commit is ready it is set\n> up to \"message\". We check If it is not empty and not NULL (:wq\n> executed), then we can commit.\n> For \"prepopulated\" messages this variable can be is set to \"message\"\n> from the beginning, so it doesn't matter if you're writing changes or\n> not the check will always be true, so we can commit.\n\nI don't understand what change you're asking for, as things already \nwork as you've just described (the \"variable\" is the file, .git/ \nCOMMIT_EDITMSG).\n\n> If the implementation would be like this, then I would propose to\n> clean up this variable after the prepopulated message is populated, so\n> it won't use it blindly, but only after you're overwriting the message\n> (even if the message is not changed).\n\nHere is where you've lost me. Not sure what you mean here, nor how \nyou're going to maintain the existing behavior for all of the people \nwho have grown used to it over a long, long period of time.\n\nWincent\n"},{"id":"133408","messageId":"76c5b8581002021431o2b5073a0s42b273b6d61893db@mail.gmail.com","threadId":"22494","inReplyTo":"77153A83-158D-4D36-A622-7AA3947C7D52@wincent.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T22:31:08Z","receivedAt":"2010-02-02T22:31:08Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> Why should Git care about how you exited from your EDITOR? All it should\n> care about is the contents of the commit message, and the exit code of the\n> editor.\n\nIt doesn't matter which editor is used. The only thing that matters is\nthat you saving or not saving on exit from editor. If not saving -\nabort the action.\n\n>\n>> For example IF there is a variable somewhere where message is stored:\n>> For new commit message it is NULL and when commit is ready it is set\n>> up to \"message\". We check If it is not empty and not NULL (:wq\n>> executed),  then we can commit.\n>> For \"prepopulated\" messages this variable can be is set to \"message\"\n>> from the beginning, so it doesn't matter if you're writing changes or\n>> not the check will always be true, so we can commit.\n>\n> I don't understand what change you're asking for, as things already work as\n> you've just described (the \"variable\" is the file, .git/COMMIT_EDITMSG).\n\nSo, i was right in my assumption about how it is implemented - good;)\n\n>\n>> If the implementation would be like this, then I would propose to\n>> clean up this variable after the prepopulated message is populated, so\n>> it won't use it blindly, but only after you're overwriting the message\n>> (even if the message is not changed).\n>\n> Here is where you've lost me. Not sure what you mean here, nor how you're\n> going to maintain the existing behavior for all of the people who have grown\n> used to it over a long, long period of time.\n\nLet me explain it like this (sorry for syntax):\n\nnew commit:\n\nCOMMIT_EDITMSG = NULL;\n$ git commit\n\nin background:\n$EDITOR .git/COMMIT_EDITMSG\n\nIf saved/written\nCOMMIT_EDITMSG=message\n\nif (COMMIT_EDITMSG != NULL && !COMMIT_EDITMSG.equalsIgnoreCase(\"\") ) {\ncommit();\n} else abort();\n\n====================\namend or rebase:\nCOMMIT_EDITMSG = \"message from commit or rebase sequence\";\n$ git commit --amend\n\nin background:\n$EDITOR .git/COMMIT_EDITMSG\n\nCOMMIT_EDITMSG = NULL <======== this i think is missing. We have to\nclean it after it is populated in the editor.\n\nIf written back by save:\nCOMMIT_EDITMSG=\"message from commit or rebase sequence\" (it was not\nchanged, but saved/written)\n\nIf not saved, the check below will abort the action\n\nif (COMMIT_EDITMSG != NULL && !COMMIT_EDITMSG.equalsIgnoreCase(\"\") ) {\ncommit();\n} else abort();\n\n\nIs that a better explanation?\n\nSo, the only change from user perspective will be that you will have\nalways save/write your changes/rebase sequences (even if you don't\nchange the message) for the program to proceed with commit\namend/rebase or whatever the same way as for the simple commit.\n\nThanks,\nEugene\n"},{"id":"133410","messageId":"32541b131002021435kadb68ffge77ad5f4e1775418@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021431o2b5073a0s42b273b6d61893db@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T22:35:59Z","receivedAt":"2010-02-02T22:35:59Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"> amend or rebase:\n> COMMIT_EDITMSG = \"message from commit or rebase sequence\";\n> $ git commit --amend\n>\n> in background:\n> $EDITOR .git/COMMIT_EDITMSG\n>\n> COMMIT_EDITMSG = NULL    <======== this i think is missing. We have to\n> clean it after it is populated in the editor.\n\nThat's not going to work. Most editors will get quite angry at you if\nyou modify the file while the editor has it open. Furthermore, how do\nyou know how long to wait after launching the editor but before\ndeleting the file?\n\nLike I suggested earlier, monitoring the mtime of the file to see if\nit has changed after the editor exits, even if the file itself is\nidentical to what it was, might work. This feature would have to be\noptional in order to not confuse existing users, and not annoy users\nof editors (like my favourite, joe) which don't save-on-exit if the\nfile hasn't changed. But I think it might be valuable to some people\nnevertheless. And if it became popular, perhaps it could become the\ndefault in some future version of git (after giving people enough\nnotice, etc, etc).\n\nSo you might want to submit a patch to implement an option like that.\n\nAvery\n"},{"id":"133412","messageId":"alpine.DEB.1.00.1002022356460.4985@pacific.mpi-cbg.de","threadId":"22494","inReplyTo":"76c5b8581002021431o2b5073a0s42b273b6d61893db@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-02T23:00:26Z","receivedAt":"2010-02-02T23:00:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Feb 2010, Eugene Sajine wrote:\n\n[somebody wrote this, I suspect it was Wincent]\n>\n> > Why should Git care about how you exited from your EDITOR? All it \n> > should care about is the contents of the commit message, and the exit \n> > code of the editor.\n> \n> It doesn't matter which editor is used. The only thing that matters is \n> that you saving or not saving on exit from editor. If not saving - abort \n> the action.\n\nNo. If not saving, then it means that the user was fine with the message \nas-is.\n\nRemember, --amend is usually for amending the _content_ of the patch, not \nso much the message.\n\nOf course, you could come up with wonderfully complicated strategies such \nas \"if nothing was added, then an unmodified commit message means 'abort', \nelse it means 'go ahead'\", but I hope that you agree that this would be \nvery bad from the users' POV: it would be utterly confusing.\n\nCiao,\nDscho\n"},{"id":"133414","messageId":"76c5b8581002021502i2bb34967y9a88d8b25ce7fa42@mail.gmail.com","threadId":"22494","inReplyTo":"32541b131002021435kadb68ffge77ad5f4e1775418@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T23:02:51Z","receivedAt":"2010-02-02T23:02:51Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Tue, Feb 2, 2010 at 5:35 PM, Avery Pennarun wrote:\n>> amend or rebase:\n>> COMMIT_EDITMSG = \"message from commit or rebase sequence\";\n>> $ git commit --amend\n>>\n>> in background:\n>> $EDITOR .git/COMMIT_EDITMSG\n>>\n>> COMMIT_EDITMSG = NULL    <======== this i think is missing. We have to\n>> clean it after it is populated in the editor.\n>\n> That's not going to work.  Most editors will get quite angry at you if\n> you modify the file while the editor has it open.  Furthermore, how do\n> you know how long to wait after launching the editor but before\n> deleting the file?\n\nI'm not insisting on this approach by any mean - i was trying to\nexplain what is the problem i consider to be a bug.\n\n\n>\n> Like I suggested earlier, monitoring the mtime of the file to see if\n> it has changed after the editor exits, even if the file itself is\n> identical to what it was, might work.\n\nAnything that would work;)\n\n>This feature would have to be\n> optional in order to not confuse existing users, and not annoy users\n> of editors (like my favourite, joe) which don't save-on-exit if the\n> file hasn't changed.  But I think it might be valuable to some people\n> nevertheless.  And if it became popular, perhaps it could become the\n> default in some future version of git (after giving people enough\n> notice, etc, etc).\n\nBut here I totally disagree, because i don't understand what is so new\nand confusing in the workflow I'm talking about?\nWhy you're not confused that you MUST save before exiting your EDITOR\nin order to be able to commit (else it will fail), but the same\nworkflow suddenly becomes confusing when you doing \"commit --amend\" or\nespecially \"rebase -i\" ???\n\nFrankly, I think that \"rebase -i\" is the best example when exiting\nwithout save should abort, not proceed.\n\n\n>\n> So you might want to submit a patch to implement an option like that.\n>\n> Avery\n>\n\nI wish i could - but, unfortunately, I'm as far from C as from the Sun\n(star;)). I'm developing a little bit in Java, but can't do C.\n\nThanks,\nEugene\n"},{"id":"133415","messageId":"alpine.DEB.1.00.1002030014100.4985@pacific.mpi-cbg.de","threadId":"22494","inReplyTo":"76c5b8581002021502i2bb34967y9a88d8b25ce7fa42@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-02T23:15:11Z","receivedAt":"2010-02-02T23:15:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Feb 2010, Eugene Sajine wrote:\n\n> Frankly, I think that \"rebase -i\" is the best example when exiting \n> without save should abort, not proceed.\n\nThat would be horrible! If the list of commits I want to apply happens to \nbe exactly what I want without needing any reordering/removing, then it \nwould abort, according to you.\n\nCiao,\nDscho\n"},{"id":"133416","messageId":"76c5b8581002021527s446fda1dh3a5001b9a4996538@mail.gmail.com","threadId":"22494","inReplyTo":"alpine.DEB.1.00.1002030014100.4985@pacific.mpi-cbg.de","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T23:27:43Z","receivedAt":"2010-02-02T23:27:43Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">> Frankly, I think that \"rebase -i\" is the best example when exiting\n>> without save should abort, not proceed.\n>\n> That would be horrible! If the list of commits I want to apply happens to\n> be exactly what I want without needing any reordering/removing, then it\n> would abort, according to you.\n>\n\nNo! It wouldn't if you save instead of simply exiting, if you type :wq\ninstead :q\n\nI'm obviously failing to express my self ...;)\n\nNOTHING is supposed to change for you except that you have to save on\nexit, write the file, confirm changes or absence of such, agree with\ngenerated content of rebase sequence. That is all i'm talking about.\n\nYou MUST save the file when you do commit - right? Because this file\nCOMMIT_EDITMSG is empty. It will fail to commit otherwise - right?\nThe problem is that this file is NOT empty when there is a\nprepopulated message like rebase -i sequence of commits or message\nfrom commit being amended.\nTherefore, you can exit without saving and the action will still\nhappen - which is wrong and not consistent with \"commit\"!\n\nExit without saving for me means FORGET what i was doing here . So, it\nis obvious, that when I'm doing rebase -i and working with the list of\ncommits exit without saving should mean - FORGET about rebase.\n\nThanks,\nEugene\n"},{"id":"133417","messageId":"76c5b8581002021534i1f0dbd18y1b216233d282cd84@mail.gmail.com","threadId":"22494","inReplyTo":"alpine.DEB.1.00.1002022356460.4985@pacific.mpi-cbg.de","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T23:34:55Z","receivedAt":"2010-02-02T23:34:55Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"> Of course, you could come up with wonderfully complicated strategies such\n> as \"if nothing was added, then an unmodified commit message means 'abort',\n> else it means 'go ahead'\", but I hope that you agree that this would be\n> very bad from the users' POV: it would be utterly confusing.\n\nNo complicated strategies necessary.\nI'm not talking about modified or not modified commit message. I'm not\nforcing anybody to modify commit message in order to proceed with\ncommit --amend.\nI'm talking about consistent behaviour of main operations:\n\nCommit - you must save on exit from your editor, simply exiting will abort.\n\nSame should be applied to rebase -i and of course to commit --amend as\nit is still commit operation.\n\nEven if the text is OK or you agree with generated sequence of rebase\n- confirm that explicitly by saving on exit from the editor, else it\nshould abort. Pretty obvious to me...;)\n\n\nThanks,\n'Eugene\n"},{"id":"133418","messageId":"40aa078e1002021540i13e35776xd733a4e40f34b477@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021534i1f0dbd18y1b216233d282cd84@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-02T23:40:27Z","receivedAt":"2010-02-02T23:40:27Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Feb 3, 2010 at 12:34 AM, Eugene Sajine wrote:\n>> Of course, you could come up with wonderfully complicated strategies such\n>> as \"if nothing was added, then an unmodified commit message means 'abort',\n>> else it means 'go ahead'\", but I hope that you agree that this would be\n>> very bad from the users' POV: it would be utterly confusing.\n>\n> No complicated strategies necessary.\n> I'm not talking about modified or not modified commit message. I'm not\n> forcing anybody to modify commit message in order to proceed with\n> commit --amend.\n> I'm talking about consistent behaviour of main operations:\n>\n> Commit - you must save on exit from your editor, simply exiting will abort.\n>\n\nThis is where you're wrong. The reason why commit (without --amend) is\naborting when you don't save is that the default commit message is\nempty, not that it wasn't saved. In fact, just saving still makes in\nabort. You need to add something to the commit message and then save\nto get it to perform the commit.\n\n> Same should be applied to rebase -i and of course to commit --amend as\n> it is still commit operation.\n>\n\n\"rebase -i\" and \"commit --amend\" already has the exact same logic as\ncommit without ammend in this regard - they abort if the buffer is\nempty.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"133419","messageId":"32541b131002021540g7a2834c9hacf2be5962f66515@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021502i2bb34967y9a88d8b25ce7fa42@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T23:40:49Z","receivedAt":"2010-02-02T23:40:49Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 6:02 PM, Eugene Sajine wrote:\n> On Tue, Feb 2, 2010 at 5:35 PM, Avery Pennarun wrote:\n>>This feature would have to be\n>> optional in order to not confuse existing users, and not annoy users\n>> of editors (like my favourite, joe) which don't save-on-exit if the\n>> file hasn't changed.  But I think it might be valuable to some people\n>> nevertheless.  And if it became popular, perhaps it could become the\n>> default in some future version of git (after giving people enough\n>> notice, etc, etc).\n>\n> But here I totally disagree, because i don't understand what is so new\n> and confusing in the workflow I'm talking about?\n> Why you're not confused that you MUST save before exiting your EDITOR\n> in order to be able to commit (else it will fail), but the same\n> workflow suddenly becomes confusing when you doing \"commit --amend\" or\n> especially \"rebase -i\" ???\n\nI think you're missing the point of people's objections.\n\nIt's pretty clear that the current behaviour is inconsistent and\nconfusing to new users:\n\n- If you make a new commit and change your mind, abort your editor:\ncommit is aborted.\n\n- If you amend a commit and change your mind, abort your editor:\ncommit gets *replaced* and newbies don't know how to get it back.\nArgh!\n\nHowever, whether it's inconsistent and confusing is unfortunately not\nthe question. The question is what can you do to possibly improve\nthings while a) not making backwards-incompatible changes, b) not\nmaking things even more inconsistent, and c) not annoying existing\nlong-term users who like it fine the way it is. (I use the current\nbehaviour and I even kind of like it now that I understand it. But I\nstill think it's confusing and admit there may be a better way.)\n\ngit development is kind of like working at Intel or Microsoft. If you\nwant to achieve world domination, you don't make new versions that are\nincompatible with old ones, no matter how stupid you think the old one\nwas.\n\nYou can however add *new* stuff. That's why I suggested adding an\noption. You could even make it a config option so you only have to\nset it once (just like setting your preferred editor).\n\n> I wish i could - but, unfortunately, I'm as far from C as from the Sun\n> (star;)). I'm developing a little bit in Java, but can't do C.\n\nThere's no better time to learn :)\n\nHave fun,\n\nAvery\n"},{"id":"133421","messageId":"7vfx5j19vg.fsf@alter.siamese.dyndns.org","threadId":"22494","inReplyTo":"alpine.DEB.1.00.1002022356460.4985@pacific.mpi-cbg.de","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-02T23:44:03Z","receivedAt":"2010-02-02T23:44:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> No. If not saving, then it means that the user was fine with the message \n> as-is.\n>\n> Remember, --amend is usually for amending the _content_ of the patch, not \n> so much the message.\n\nI very often use --amend to update only the message, so I would strongly\ndisagree with the \"usually\".\n\nBut that doesn't change my conclusion ;-) It is immaterial if you amended\nthe tree or the message. If either or both changed, we do need to create\na new commit---there is no question about it, so which one is more often\ndone does not matter. Eugene does not gain anything by \"Remember\"ing it.\n\nWhat is more important is what to do when neither changed.\n\nIf you run \"rebase -i\" and leave the earlier \"pick\"s intact, it seems to\ntry keeping the commits intact, instead of rewriting.\n\nIt is understandable if somebody wanted to keep using the old commit\nobject when the committer timestamp is the _only_ thing that is different\nbetween the original and the amended commit, after \"git commit --amend\" is\nrun. Essentially, the behaviour of \"rebase -i\" for earlier \"pick\"s comes\nfrom the same motivation.\n\nRight now, if you run this in a loop:\n\n while hell has not frozen over\n do\n\tgit reset && EDITOR=: git commit --amend\n done\n\nit will keep generating almost identical commits, except for their\ncommitter timestamps. The very first one may have different committer\nidentity from the original if you are amending somebody else's commit, but\nafter that it will be all you over and over again, only at different\ntimes.\n\nI am inclined to say that it is a feature that it updates the commit in\nsuch a case to record the _last time_ you touched the commit. You ran\n\"commit --amend\" and did not use the any published method to _abort_ the\namend.\n\nAs mentioned already, @{1} is your friend. Regardless of the difference\nbetween @{0} and @{1}, it is a way to go back to the previous commit if\nyou do not like the latest commit for whatever reason; the latest commit\nmay have a \"wrong tree\", a \"wrong message\", or a \"wrong committer\ntimestamp\".\n"},{"id":"133423","messageId":"76c5b8581002021548n129b3997r48ee6f6df5a1a4eb@mail.gmail.com","threadId":"22494","inReplyTo":"40aa078e1002021540i13e35776xd733a4e40f34b477@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-02T23:48:13Z","receivedAt":"2010-02-02T23:48:13Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":">\n> This is where you're wrong. The reason why commit (without --amend) is\n> aborting when you don't save is that the default commit message is\n> empty, not that it wasn't saved. In fact, just saving still makes in\n> abort. You need to add something to the commit message and then save\n> to get it to perform the commit.\n>\n>> Same should be applied to rebase -i and of course to commit --amend as\n>> it is still commit operation.\n>>\n>\n> \"rebase -i\" and \"commit --amend\" already has the exact same logic as\n> commit without ammend in this regard - they abort if the buffer is\n> empty.\n>\n> --\n> Erik \"kusma\" Faye-Lund\n>\n\nThank you, but I'm not wrong, as i described the exact same thing\nsomewhere in my second or third message, without even knowing the\nimplementation details. I understand the reason WHY it is like it is,\ni just don't like it as it is inconsistent and IMHO incorrect.\n\nThanks,\nEugene\n"},{"id":"133424","messageId":"alpine.DEB.1.00.1002030056480.4985@pacific.mpi-cbg.de","threadId":"22494","inReplyTo":"76c5b8581002021534i1f0dbd18y1b216233d282cd84@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-02T23:58:59Z","receivedAt":"2010-02-02T23:58:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Feb 2010, Eugene Sajine wrote:\n\n> > Of course, you could come up with wonderfully complicated strategies \n> > such as \"if nothing was added, then an unmodified commit message means \n> > 'abort', else it means 'go ahead'\", but I hope that you agree that \n> > this would be very bad from the users' POV: it would be utterly \n> > confusing.\n> \n> No complicated strategies necessary.\n\nSorry, your \"if message was not saved, abort\" is so out of line with any \nprogram I use that this would be highly confusing (maybe \"complicated\" was \nthe wrong choice of words).\n\nIMO it would not buy us anything over the current solution, which also \nrequires the user to read the manual.\n\nCiao,\nDscho\n"},{"id":"133427","messageId":"76c5b8581002021609i4c05d039k35979757fbb74676@mail.gmail.com","threadId":"22494","inReplyTo":"alpine.DEB.1.00.1002030056480.4985@pacific.mpi-cbg.de","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T00:09:10Z","receivedAt":"2010-02-03T00:09:10Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"> Sorry, your \"if message was not saved, abort\" is so out of line with any\n> program I use that this would be highly confusing (maybe \"complicated\" was\n> the wrong choice of words).\n\nFrankly, i think it is in line with \"git commit\" and that's the only\nthing that matters here as I have no idea what programs you're talking\nabout. If your programs are working without making sure that user\nconfirmed whatever he actually supposed to confirm, then you probably\nshould revisit them;)\n\nThanks,\nEugene\n"},{"id":"133428","messageId":"40aa078e1002021616s3098bf53la6af93ab0949e7e@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002021548n129b3997r48ee6f6df5a1a4eb@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-03T00:16:57Z","receivedAt":"2010-02-03T00:16:57Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine wrote:\n>>\n>> This is where you're wrong. The reason why commit (without --amend) is\n>> aborting when you don't save is that the default commit message is\n>> empty, not that it wasn't saved. In fact, just saving still makes in\n>> abort. You need to add something to the commit message and then save\n>> to get it to perform the commit.\n>>\n>>> Same should be applied to rebase -i and of course to commit --amend as\n>>> it is still commit operation.\n>>>\n>>\n>> \"rebase -i\" and \"commit --amend\" already has the exact same logic as\n>> commit without ammend in this regard - they abort if the buffer is\n>> empty.\n>>\n>> --\n>> Erik \"kusma\" Faye-Lund\n>>\n>\n> Thank you, but I'm not wrong, as i described the exact same thing\n> somewhere in my second or third message, without even knowing the\n> implementation details. I understand the reason WHY it is like it is,\n> i just don't like it as it is inconsistent and IMHO incorrect.\n>\n\nBut you are. The interface isn't inconsistent. Your model of how it\nworks however, is wrong.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"133430","messageId":"76c5b8581002021655k5f63b81h1c55ae87625fbfc5@mail.gmail.com","threadId":"22494","inReplyTo":"40aa078e1002021616s3098bf53la6af93ab0949e7e@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T00:55:31Z","receivedAt":"2010-02-03T00:55:31Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund wrote:\n> On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine wrote:\n>>>\n>>> This is where you're wrong. The reason why commit (without --amend) is\n>>> aborting when you don't save is that the default commit message is\n>>> empty, not that it wasn't saved. In fact, just saving still makes in\n>>> abort. You need to add something to the commit message and then save\n>>> to get it to perform the commit.\n>>>\n>>>> Same should be applied to rebase -i and of course to commit --amend as\n>>>> it is still commit operation.\n>>>>\n>>>\n>>> \"rebase -i\" and \"commit --amend\" already has the exact same logic as\n>>> commit without ammend in this regard - they abort if the buffer is\n>>> empty.\n>>>\n>>> --\n>>> Erik \"kusma\" Faye-Lund\n>>>\n>>\n>> Thank you, but I'm not wrong, as i described the exact same thing\n>> somewhere in my second or third message, without even knowing the\n>> implementation details. I understand the reason WHY it is like it is,\n>> i just don't like it as it is inconsistent and IMHO incorrect.\n>>\n>\n> But you are. The interface isn't inconsistent. Your model of how it\n> works however, is wrong.\n>\n> --\n> Erik \"kusma\" Faye-Lund\n>\n\nI'm sorry, but I don't get in which part my model is so wrong? The only\ndifference i see between your and my explanation is that you mentioned the\nfact that simply saving the pregenerated new commit message is not working\nbecause there is no meaningful (uncommented) string inserted into the\ntemplate. But this\ndoesn't change the problem it self, so I don't think it is relevant.\n\nWhat is relevant though is that in current workflow with \"rebase -i\"\nyou have to remove! all\ncommits listed for rebase and save! the file in order to cancel! rebase\noperation. This is very strange user interaction model IMHO\n\nInstead of being explicit in applying the changes, we are explicit in\ncancelling the operation. Very strange...\n\nThanks,\nEugene\n"},{"id":"133435","messageId":"20100203015947.GA4280@neumann","threadId":"22494","inReplyTo":"76c5b8581002021655k5f63b81h1c55ae87625fbfc5@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-02-03T01:59:47Z","receivedAt":"2010-02-03T01:59:47Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Feb 02, 2010 at 07:55:31PM -0500, Eugene Sajine wrote:\n> On Tue, Feb 2, 2010 at 7:16 PM, Erik Faye-Lund wrote:\n> > On Wed, Feb 3, 2010 at 12:48 AM, Eugene Sajine wrote:\n> >>>\n> >>> This is where you're wrong. The reason why commit (without --amend) is\n> >>> aborting when you don't save is that the default commit message is\n> >>> empty, not that it wasn't saved. In fact, just saving still makes in\n> >>> abort. You need to add something to the commit message and then save\n> >>> to get it to perform the commit.\n> >>>\n> >>>> Same should be applied to rebase -i and of course to commit --amend as\n> >>>> it is still commit operation.\n> >>>>\n> >>>\n> >>> \"rebase -i\" and \"commit --amend\" already has the exact same logic as\n> >>> commit without ammend in this regard - they abort if the buffer is\n> >>> empty.\n> >>>\n> >>> --\n> >>> Erik \"kusma\" Faye-Lund\n> >>>\n> >>\n> >> Thank you, but I'm not wrong, as i described the exact same thing\n> >> somewhere in my second or third message, without even knowing the\n> >> implementation details. I understand the reason WHY it is like it is,\n> >> i just don't like it as it is inconsistent and IMHO incorrect.\n> >>\n> >\n> > But you are. The interface isn't inconsistent. Your model of how it\n> > works however, is wrong.\n> >\n> > --\n> > Erik \"kusma\" Faye-Lund\n> >\n> \n> I'm sorry, but I don't get in which part my model is so wrong? The only\n> difference i see between your and my explanation is that you mentioned the\n> fact that simply saving the pregenerated new commit message is not working\n> because there is no meaningful (uncommented) string inserted into the\n> template. But this\n> doesn't change the problem it self, so I don't think it is relevant.\n> \n> What is relevant though is that in current workflow with \"rebase -i\"\n> you have to remove! all\n> commits listed for rebase and save! the file in order to cancel! rebase\n> operation. This is very strange user interaction model IMHO\n> \n> Instead of being explicit in applying the changes, we are explicit in\n> cancelling the operation. Very strange...\n\nNo. In case of rebase -i, exiting the editor is being explicit in\n\"the todo file now contains what you should do, so do it\". And if the\ntodo file happens to be empty, then there is nothing to do, so do\nnothing. The same applies to commit and commit --amend: exiting the\neditor is being explicit in \"the COMMIT_MSG file now contains what you\nshould put in the commit message\". But not having a commit message is\na really bad idea, therefore git complains and doesn't do that (unless\noverridden by some command line option).\n\n\nBest,\nGábor\n"},{"id":"133444","messageId":"20100203061535.GA6566@cthulhu","threadId":"22494","inReplyTo":"32541b131002021540g7a2834c9hacf2be5962f66515@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Larry D'Anna","fromEmail":"larry@elder-gods.org","sentAt":"2010-02-03T06:15:35Z","receivedAt":"2010-02-03T06:15:35Z","isPatch":false,"sender":{"key":"larry@elder-gods.org","avatar":"https://avatars.githubusercontent.com/u/3013304?v=4"},"body":"* Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:\n> You can however add *new* stuff. That's why I suggested adding an\n> option. You could even make it a config option so you only have to\n> set it once (just like setting your preferred editor).\n\nOr, he can set his $EDITOR to a script that checks the mtime.\n\n --larry\n"},{"id":"133446","messageId":"vpqeil2kc6b.fsf@bauges.imag.fr","threadId":"22494","inReplyTo":"76c5b8581002021548n129b3997r48ee6f6df5a1a4eb@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-02-03T07:31:40Z","receivedAt":"2010-02-03T07:31:40Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Eugene Sajine writes:\n\n> Thank you, but I'm not wrong, as i described the exact same thing\n> somewhere in my second or third message, without even knowing the\n> implementation details. I understand the reason WHY it is like it is,\n> i just don't like it as it is inconsistent and IMHO incorrect.\n\nJust try:\n\nCreate a file.\n1) Launch emacs, save and quit.\n2) Launch emacs, don't save, and quit.\n\n>From outside, it's EXACTLY the same thing. In the first case, emacs\nwill just tell you \"no change need to be saved\" and quit, in the\nsecond, it'll quit. Try deleting the file in the meantime, it won't\nchange the behavior.\n\nNow, what would you do about this? Ignore Emacs and force people to\nuse vi?\n\nPeople have been spending a whole thread to explain you that it's not\ngoing to work. I think it'll either be time to acknowledge that, or to\nlearn C and write a patch. Or perhaps try to write it in Java to\nunderstand why it doesn't work.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"133447","messageId":"vpqaavqkc1s.fsf@bauges.imag.fr","threadId":"22494","inReplyTo":"20100203015947.GA4280@neumann","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-02-03T07:34:23Z","receivedAt":"2010-02-03T07:34:23Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"SZEDER Gábor writes:\n\n> No. In case of rebase -i, exiting the editor is being explicit in\n> \"the todo file now contains what you should do, so do it\". And if the\n> todo file happens to be empty, then there is nothing to do, so do\n> nothing.\n\nIt's not true. The todolist is the list of things to do after you\nrewind your branch to the destination branch. Strictly speaking, an\nempty todolist should mean to drop all the patches (like a todolist\nwith just one line would mean to drop all the others). But a user\nnever wants to do that (otherwise, \"git reset\" would be the right\ncommand), so \"git rebase -i\" considers it as a special case.\n\nMy 2 cents,\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"133451","messageId":"alpine.DEB.1.00.1002031003250.3099@intel-tinevez-2-302","threadId":"22494","inReplyTo":"76c5b8581002021609i4c05d039k35979757fbb74676@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-03T09:04:30Z","receivedAt":"2010-02-03T09:04:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 2 Feb 2010, Eugene Sajine wrote:\n\n> > Sorry, your \"if message was not saved, abort\" is so out of line with \n> > any program I use that this would be highly confusing (maybe \n> > \"complicated\" was the wrong choice of words).\n> \n> Frankly, i think it is in line with \"git commit\" and that's the only \n> thing that matters here as I have no idea what programs you're talking \n> about.\n\nIt's not. 'git commit' will abort if you delete all _and save_. So it is \nnot the saving part, it is the deleting all part. And that's exactly how \nrebase -i works, or add -e: if you delete all and save, it aborts.\n\nCiao,\nDscho\n"},{"id":"133453","messageId":"alpine.DEB.1.00.1002031006570.3099@intel-tinevez-2-302","threadId":"22494","inReplyTo":"vpqaavqkc1s.fsf@bauges.imag.fr","subject":"aborting rebase -i right at the start, was Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-03T09:08:50Z","receivedAt":"2010-02-03T09:08:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 3 Feb 2010, Matthieu Moy wrote:\n\n> Strictly speaking, an empty [rebase -i] todolist should mean to drop all \n> the patches (like a todolist with just one line would mean to drop all \n> the others). But a user never wants to do that (otherwise, \"git reset\" \n> would be the right command), so \"git rebase -i\" considers it as a \n> special case.\n\nActually, it is a design bug, but it was the only sane way I could think \nof aborting the rebase.\n\nNote that there _are_ users who want to do that (\"let me see what commits \nI have, ah, oh, okay, I want none of them\"). I am one of those. That's \nwhere the underadvertised \"noop\" command comes in.\n\nCiao,\nDscho\n"},{"id":"133454","messageId":"20100203093150.GA23956@coredump.intra.peff.net","threadId":"22494","inReplyTo":"20100203061535.GA6566@cthulhu","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-03T09:31:51Z","receivedAt":"2010-02-03T09:31:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 03, 2010 at 01:15:35AM -0500, Larry D'Anna wrote:\n\n> * Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:\n> > You can however add *new* stuff. That's why I suggested adding an\n> > option. You could even make it a config option so you only have to\n> > set it once (just like setting your preferred editor).\n> \n> Or, he can set his $EDITOR to a script that checks the mtime.\n\nAgreed. It could even look like this:\n\n-- >8 --\n$ cat >vi-must-edit <<'EOF'\n#!/usr/bin/perl\nsub mtime { (stat $_[0])[9] }\nmy $old = mtime($ARGV[-1]);\nsystem('vi', @ARGV) and die \"vi failed\";\nif (mtime($ARGV[-1]) == $old) {\n print STDERR \"Aborting unmodified message\\n\";\n exit 1;\n}\nexit 0\nEOF\n$ chmod +x vi-must-edit\n$ GIT_EDITOR=$PWD/vi-must-edit; export GIT_EDITOR\n$ git commit --amend ;# and then quit the editor immediately\nAborting unmodified message\nerror: There was a problem with the editor 'vi-must-edit'.\nPlease supply the message using either -m or -F option.\n\n-- 8< --\n\nDo note, though, that there is a subtle race condition in using the\nmtime. If you make a change and save within a second of the editor\nstarting, it will be ignored. To be thorough, you would probably want to\ncheck the size and inode, as well.\n\n-Peff\n"},{"id":"133455","messageId":"20100203094144.GM15202@neumann","threadId":"22494","inReplyTo":"alpine.DEB.1.00.1002031006570.3099@intel-tinevez-2-302","subject":"Re: aborting rebase -i right at the start, was Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-02-03T09:41:44Z","receivedAt":"2010-02-03T09:41:44Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 3 Feb 2010, Matthieu Moy wrote:\n> \n> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all \n> > the patches (like a todolist with just one line would mean to drop all \n> > the others). But a user never wants to do that (otherwise, \"git reset\" \n> > would be the right command), so \"git rebase -i\" considers it as a \n> > special case.\n> \n> Actually, it is a design bug, but it was the only sane way I could think \n> of aborting the rebase.\n> \n> Note that there _are_ users who want to do that (\"let me see what commits \n> I have, ah, oh, okay, I want none of them\"). I am one of those.\n\nI regularly mess up the todo file so badly that I don't want to bother\nwith undo but rather start over from the beginning.\n\n\nBest,\nGábor\n"},{"id":"133456","messageId":"hkbgli$tqt$1@ger.gmane.org","threadId":"22494","inReplyTo":"76c5b8581002021609i4c05d039k35979757fbb74676@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2010-02-03T09:46:27Z","receivedAt":"2010-02-03T09:46:27Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"On 02/03/2010 01:09 AM, Eugene Sajine wrote:\n>> Sorry, your \"if message was not saved, abort\" is so out of line with any\n>> program I use that this would be highly confusing (maybe \"complicated\" was\n>> the wrong choice of words).\n>\n> Frankly, i think it is in line with \"git commit\"\n\nThe fundamental problem is this. The behavior of \"git commit\" can be \nexplained in two ways: a) abort if not saved; b) abort if empty. (a) \nmay be an easier guess from experience (you type \":q!\" at the vi \nprompt), but (b) is clear from the error message (\"commit has empty \nmessage--aborting\"). All this is irrefutable.\n\nNow, the scientific method to see which one is correct, would be to try \nother commands including \"git commit --amend\" and see which of the two \nhypotheses was right. It turns out to be that (b) is correct and \nconsistent across various commands; instead you insist that everything \nelse should be modified to conform to (a). Since git is already \nconsistent, and since nobody can think of a way to implement your \nproposal, there is obvious resistence to any change in this area.\n\nPaolo\n"},{"id":"133460","messageId":"20100203101509.GA25336@coredump.intra.peff.net","threadId":"22494","inReplyTo":"20100203093150.GA23956@coredump.intra.peff.net","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-03T10:15:09Z","receivedAt":"2010-02-03T10:15:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 03, 2010 at 04:31:50AM -0500, Jeff King wrote:\n\n> > Or, he can set his $EDITOR to a script that checks the mtime.\n> \n> Agreed. It could even look like this:\n\nAlso, while we are talking about editor-specific hacks, if you are using\nvim you can use \":cq\" to exit with an error code.\n\n-Peff\n"},{"id":"133474","messageId":"76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com","threadId":"22494","inReplyTo":"vpqeil2kc6b.fsf@bauges.imag.fr","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T15:45:54Z","receivedAt":"2010-02-03T15:45:54Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy\n wrote:\n> Eugene Sajine writes:\n>\n>> Thank you, but I'm not wrong, as i described the exact same thing\n>> somewhere in my second or third message, without even knowing the\n>> implementation details. I understand the reason WHY it is like it is,\n>> i just don't like it as it is inconsistent and IMHO incorrect.\n>\n> Just try:\n>\n> Create a file.\n> 1) Launch emacs, save and quit.\n> 2) Launch emacs, don't save, and quit.\n>\n> From outside, it's EXACTLY the same thing. In the first case, emacs\n> will just tell you \"no change need to be saved\" and quit, in the\n> second, it'll quit. Try deleting the file in the meantime, it won't\n> change the behavior.\n>\n> Now, what would you do about this? Ignore Emacs and force people to\n> use vi?\n>\n> People have been spending a whole thread to explain you that it's not\n> going to work. I think it'll either be time to acknowledge that, or to\n> learn C and write a patch. Or perhaps try to write it in Java to\n> understand why it doesn't work.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n>\n\nTell me you're not serious, please;) I'm working with computers for\nmore than 20 years and I do understand how editors are opening files.\nIf you are serious though...:\n\nPlease, do not assume i don't understand that file opened in editor\nand saved with no changes will be the same as not saved.\n\nPlease, do not assume i don't understand that current implementation\ndoes not allow to correctly abort by simply quiting the editor,\nbecause it uses the file content only to verify if it can proceed.\n\n\nI will stop trying to explain the problem here, but the solution, that\ni think should work:\n\nThe solution should be as Avery proposed - to monitor file\nmodification timestamp as well as the content.\nTimestamp should be remembered by git when editor is fired up and then\nchecked when you're exiting the editor. If it is the same - it means\nthat user canceled the whole operation by not confirming the file\ncontent by save. If the timestamp is bigger than the saved one and the\nmessage is not empty - we can proceed. Something like that.\n\nAnd finally:\n\nI DO highly appreciate everybody's time spent on every discussion and\nparticularly this one. I ask you to excuse me if i was failing to\nproperly express my thoughts or if i was too emotional at times.\n\nThanks a lot,\nEugene\n"},{"id":"133479","messageId":"76c5b8581002030802h7be8c1b2k6aa41ba7e9db0f2b@mail.gmail.com","threadId":"22494","inReplyTo":"20100203094144.GM15202@neumann","subject":"Re: aborting rebase -i right at the start, was Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T16:02:35Z","receivedAt":"2010-02-03T16:02:35Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"2010/2/3 SZEDER Gábor :\n> On Wed, Feb 03, 2010 at 10:08:50AM +0100, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Wed, 3 Feb 2010, Matthieu Moy wrote:\n>>\n>> > Strictly speaking, an empty [rebase -i] todolist should mean to drop all\n>> > the patches (like a todolist with just one line would mean to drop all\n>> > the others). But a user never wants to do that (otherwise, \"git reset\"\n>> > would be the right command), so \"git rebase -i\" considers it as a\n>> > special case.\n>>\n>> Actually, it is a design bug, but it was the only sane way I could think\n>> of aborting the rebase.\n>>\n>> Note that there _are_ users who want to do that (\"let me see what commits\n>> I have, ah, oh, okay, I want none of them\"). I am one of those.\n>\n> I regularly mess up the todo file so badly that I don't want to bother\n> with undo but rather start over from the beginning.\n>\n>\n> Best,\n> Gábor\n>\n>\n\nI already described the solution which i think should be implemented\nin old thread I will just repeat it here for easier tracking:\n\nThe solution should be as Avery proposed - to monitor file\nmodification timestamp as well as the content.\nTimestamp should be remembered by git when editor is fired up and then\nchecked when you're exiting the editor. If it is the same - it means\nthat user canceled the whole operation by *not* confirming the file\ncontent by save. If the timestamp is bigger than the saved one and the\nmessage is not empty - we can proceed.\n\nI.e. in case of rebase -i you will be able to abort the operation by\nsimply exiting the editor without save in any state at any moment and\nstart from the beginning.\n\nThanks,\nEugene\n"},{"id":"133486","messageId":"20100203175118.GA2982@progeny.tock","threadId":"22494","inReplyTo":"76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-02-03T17:51:19Z","receivedAt":"2010-02-03T17:51:19Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eugene Sajine wrote:\n> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy\n\n>> Just try:\n>>\n>> Create a file.\n>> 1) Launch emacs, save and quit.\n>> 2) Launch emacs, don't save, and quit.\n>>\n>> From outside, it's EXACTLY the same thing. In the first case, emacs\n>> will just tell you \"no change need to be saved\" and quit, in the\n>> second, it'll quit. Try deleting the file in the meantime, it won't\n>> change the behavior.\n\n> Please, do not assume i don't understand that file opened in editor\n> and saved with no changes will be the same as not saved.\n> \n> Please, do not assume i don't understand that current implementation\n> does not allow to correctly abort by simply quiting the editor,\n> because it uses the file content only to verify if it can proceed.\n\nI’ll bite. Please reread Mattheiu’s message. Pay particular attention\nto the lines\n\n\tIn the first case, emacs\n\twill just tell you \"no change need to be saved\" and quit, in the\n\tsecond, it'll quit.\n\nand\n\n\tTry deleting the file in the meantime, it won't\n\tchange the behavior.\n\nand consider what this means about what is happening and the resulting\nstat() information.\n\nIt is a bit frustrating to read this thread because Mattheiu was not the\nfirst thing to say this (and many have mentioned other problems, too,\nsuch as people’s muscle memory), but you do not seem to respond to them.\nInstead, you keep repeating the same thing...\n\nHope that helps,\nJonathan\n"},{"id":"133487","messageId":"20100203175304.GB2982@progeny.tock","threadId":"22494","inReplyTo":"20100203175118.GA2982@progeny.tock","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-02-03T17:53:04Z","receivedAt":"2010-02-03T17:53:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> It is a bit frustrating to read this thread because Mattheiu was not the\n> first thing to say this\n\ns/thing/person/\n\nSorry, Mattheiu. ;-)\n\nKind regards,\nJonathan\n"},{"id":"133489","messageId":"32541b131002031019l42d3903cs58303a546f019898@mail.gmail.com","threadId":"22494","inReplyTo":"20100203093150.GA23956@coredump.intra.peff.net","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-03T18:19:41Z","receivedAt":"2010-02-03T18:19:41Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Feb 3, 2010 at 4:31 AM, Jeff King wrote:\n> On Wed, Feb 03, 2010 at 01:15:35AM -0500, Larry D'Anna wrote:\n>> * Avery Pennarun (apenwarr@gmail.com) [100202 18:41]:\n>> > You can however add *new* stuff.  That's why I suggested adding an\n>> > option.  You could even make it a config option so you only have to\n>> > set it once (just like setting your preferred editor).\n>>\n>> Or, he can set his $EDITOR to a script that checks the mtime.\n\nNice.\n\n> Do note, though, that there is a subtle race condition in using the\n> mtime. If you make a change and save within a second of the editor\n> starting, it will be ignored. To be thorough, you would probably want to\n> check the size and inode, as well.\n\nOr just the file contents.\n\nAvery\n"},{"id":"133498","messageId":"1088CD70-9D6E-4B97-9A46-BDDE1535B703@wincent.com","threadId":"22494","inReplyTo":"76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-02-03T18:21:18Z","receivedAt":"2010-02-03T18:21:18Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 03/02/2010, a las 16:45, Eugene Sajine escribió:\n\n> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy\n> wrote:\n>> Eugene Sajine writes:\n>>\n>>> Thank you, but I'm not wrong, as i described the exact same thing\n>>> somewhere in my second or third message, without even knowing the\n>>> implementation details. I understand the reason WHY it is like it \n>>> is,\n>>> i just don't like it as it is inconsistent and IMHO incorrect.\n>>\n>> Just try:\n>>\n>> Create a file.\n>> 1) Launch emacs, save and quit.\n>> 2) Launch emacs, don't save, and quit.\n>>\n>> From outside, it's EXACTLY the same thing. In the first case, emacs\n>> will just tell you \"no change need to be saved\" and quit, in the\n>> second, it'll quit. Try deleting the file in the meantime, it won't\n>> change the behavior.\n>>\n>> Now, what would you do about this? Ignore Emacs and force people to\n>> use vi?\n>>\n>> People have been spending a whole thread to explain you that it's not\n>> going to work. I think it'll either be time to acknowledge that, or \n>> to\n>> learn C and write a patch. Or perhaps try to write it in Java to\n>> understand why it doesn't work.\n>>\n>> --\n>> Matthieu Moy\n>> http://www-verimag.imag.fr/~moy/\n>>\n>\n> Tell me you're not serious, please;) I'm working with computers for\n> more than 20 years and I do understand how editors are opening files.\n> If you are serious though...:\n>\n> Please, do not assume i don't understand that file opened in editor\n> and saved with no changes will be the same as not saved.\n>\n> Please, do not assume i don't understand that current implementation\n> does not allow to correctly abort by simply quiting the editor,\n> because it uses the file content only to verify if it can proceed.\n>\n>\n> I will stop trying to explain the problem here, but the solution, that\n> i think should work:\n>\n> The solution should be as Avery proposed - to monitor file\n> modification timestamp as well as the content.\n> Timestamp should be remembered by git when editor is fired up and then\n> checked when you're exiting the editor. If it is the same - it means\n> that user canceled the whole operation by not confirming the file\n> content by save. If the timestamp is bigger than the saved one and the\n> message is not empty - we can proceed. Something like that.\n>\n> And finally:\n>\n> I DO highly appreciate everybody's time spent on every discussion and\n> particularly this one. I ask you to excuse me if i was failing to\n> properly express my thoughts or if i was too emotional at times.\n\nPerhaps you could invest a little time actually reading what people \nhave written. Your proposal won't work because in the case where the \nuser wants to keep the commit message without any modifications many \neditors won't touch the file even if people explicitly save it.\n\nWincent\n"},{"id":"133495","messageId":"vpqzl3q2m2n.fsf@bauges.imag.fr","threadId":"22494","inReplyTo":"76c5b8581002030745g634d6ec1hb9e87b687e58e521@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-02-03T18:47:28Z","receivedAt":"2010-02-03T18:47:28Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Eugene Sajine writes:\n\n> Tell me you're not serious, please;) I'm working with computers for\n> more than 20 years and I do understand how editors are opening files.\n> If you are serious though...:\n\nI'm damned serious. If you've been working for 20 years with\ncomputers, you probably understand what \"no change need to be saved\"\nmean.\n\n> The solution should be as Avery proposed - to monitor file\n> modification timestamp as well as the content.\n\nTry it. I do mean \"try it\". I don't think anyone will be able to\nexplain you better than it has already been done, but ... it doesn't\nwork.\n\nSo, again, stop arguing, try it, and see by yourself. I promise public\napologies if you prove me wrong with an actually working piece of\ncode.\n\n> Timestamp should be remembered by git when editor is fired up and then\n> checked when you're exiting the editor.\n\nWhich doesn't work reliable, as you would have noticed by reading my\nmessage.\n\n(and yes, I'm tired and angry after a long day of work ;-) ).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"133497","messageId":"76c5b8581002031049t5558a700qe2e05bb70d175305@mail.gmail.com","threadId":"22494","inReplyTo":"1088CD70-9D6E-4B97-9A46-BDDE1535B703@wincent.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T18:49:46Z","receivedAt":"2010-02-03T18:49:46Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"On Wed, Feb 3, 2010 at 1:21 PM, Wincent Colaiuta wrote:\n> El 03/02/2010, a las 16:45, Eugene Sajine escribió:\n>\n>> On Wed, Feb 3, 2010 at 2:31 AM, Matthieu Moy\n>> wrote:\n>>>\n>>> Eugene Sajine writes:\n>>>\n>>>> Thank you, but I'm not wrong, as i described the exact same thing\n>>>> somewhere in my second or third message, without even knowing the\n>>>> implementation details. I understand the reason WHY it is like it is,\n>>>> i just don't like it as it is inconsistent and IMHO incorrect.\n>>>\n>>> Just try:\n>>>\n>>> Create a file.\n>>> 1) Launch emacs, save and quit.\n>>> 2) Launch emacs, don't save, and quit.\n>>>\n>>> From outside, it's EXACTLY the same thing. In the first case, emacs\n>>> will just tell you \"no change need to be saved\" and quit, in the\n>>> second, it'll quit. Try deleting the file in the meantime, it won't\n>>> change the behavior.\n>>>\n>>> Now, what would you do about this? Ignore Emacs and force people to\n>>> use vi?\n>>>\n>>> People have been spending a whole thread to explain you that it's not\n>>> going to work. I think it'll either be time to acknowledge that, or to\n>>> learn C and write a patch. Or perhaps try to write it in Java to\n>>> understand why it doesn't work.\n>>>\n>>> --\n>>> Matthieu Moy\n>>> http://www-verimag.imag.fr/~moy/\n>>>\n>>\n>> Tell me you're not serious, please;) I'm working with computers for\n>> more than 20 years and I do understand how editors are opening files.\n>> If you are serious though...:\n>>\n>> Please, do not assume i don't understand that file opened in editor\n>> and saved with no changes will be the same as not saved.\n>>\n>> Please, do not assume i don't understand that current implementation\n>> does not allow to correctly abort by simply quiting the editor,\n>> because it uses the file content only to verify if it can proceed.\n>>\n>>\n>> I will stop trying to explain the problem here, but the solution, that\n>> i think should work:\n>>\n>> The solution should be as Avery proposed - to monitor file\n>> modification timestamp as well as the content.\n>> Timestamp should be remembered by git when editor is fired up and then\n>> checked when you're exiting the editor. If it is the same - it means\n>> that user canceled the whole operation by not confirming the file\n>> content by save. If the timestamp is bigger than the saved one and the\n>> message is not empty - we can proceed. Something like that.\n>>\n>> And finally:\n>>\n>> I DO highly appreciate everybody's time spent on every discussion and\n>> particularly this one. I ask you to excuse me if i was failing to\n>> properly express my thoughts or if i was too emotional at times.\n>\n> Perhaps you could invest a little time actually reading what people have\n> written. Your proposal won't work because in the case where the user wants\n> to keep the commit message without any modifications many editors won't\n> touch the file even if people explicitly save it.\n>\n> Wincent\n>\n>\n\nThank you for clarifying that.\n\nOK. I admit I got confused with the fact that some editors (vi,\nkwrite, gedit - i just tested them to be 100% sure) do allow you to\nhit save right after the file was opened and the timestamp will be\nchanged, while emacs or open office writer or some others do not, if\nno changes has been made. Therefore there is no way to actually change\nthe timestamp on the file from editors like emacs without actually\nchanging something.\n\nI'm very sorry for confusion, so, please, accept my apologies for\nbeing stubborn.\n\nI hope it is clear that my only intention is to try to make git better\nand provide useful feedback and I'm sorry i didn't succeed this time.\n\nThanks,\nEugene\n"},{"id":"133499","messageId":"32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002031049t5558a700qe2e05bb70d175305@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-03T18:57:55Z","receivedAt":"2010-02-03T18:57:55Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Feb 3, 2010 at 1:49 PM, Eugene Sajine wrote:\n> OK. I admit I got confused with the fact that some editors (vi,\n> kwrite, gedit - i just tested them to be 100% sure) do allow you to\n> hit save right after the file was opened and the timestamp will be\n> changed, while emacs or open office writer or some others do not, if\n> no changes has been made. Therefore there is no way to actually change\n> the timestamp on the file from editors like emacs without actually\n> changing something.\n\nOf course, in such editors you could just hit \"space; backspace\" and\nthen save. Sounds annoying? Well, so does deleting all the lines in\nthe commit message just to make it *not* amend.\n\nTo reiterate what I said earlier: the mtime idea isn't even\nautomatically a bad one. It's about as good as what currently exists,\nand the resulting rule (file content or mtime must be modified) is\njust as consistent as the current rule (file must be nonempty). It's\nalso arguably easier for new users to understand.\n\nBut you can't just blindly change the system to always work in a\ndifferent way. People depend on the current behaviour. Jeff King's\nscript is a pretty cute solution that lets you have it your way with\nno changes to git, though.\n\nOf course, this does open up the question of how to do any global UI\ndesign at all if a decision made once gets locked in forever. The\nreason git is hard for new users is that its UI is crazy and\nconfusing, but a major reason it keeps gaining in popularity is that\nonce you learn git, you stick with it, because you don't have to\nrelearn it with every new version.\n\nHave fun,\n\nAvery\n"},{"id":"133504","messageId":"76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com","threadId":"22494","inReplyTo":"32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2010-02-03T19:27:16Z","receivedAt":"2010-02-03T19:27:16Z","isPatch":false,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"> Of course, in such editors you could just hit \"space; backspace\" and\n> then save.  Sounds annoying?  Well, so does deleting all the lines in\n> the commit message just to make it *not* amend.\n\nThat was exactly the starting point of my thoughts.Currently it forces\nuser to be explicit if he wants to cancel the operation (rebase -i,\nor amend), instead of forcing user to be explicit to proceed.\n\n>\n> To reiterate what I said earlier: the mtime idea isn't even\n> automatically a bad one.  It's about as good as what currently exists,\n> and the resulting rule (file content or mtime must be modified) is\n> just as consistent as the current rule (file must be nonempty).  It's\n> also arguably easier for new users to understand.\n\nOK. Agree on that.\n\n>\n> But you can't just blindly change the system to always work in a\n> different way.  People depend on the current behaviour.\n\nI understand that pretty well. My logic is that the most used command\nwhich is affecting the three is \"git commit\", therefore this command\nworkflow is pretty natural for all users, but the workflow of commit\n--amend and rebase -i which are also affecting the three is\ninconsistent with commit. The user interaction is not the same.\n\n> Jeff King's script is a pretty cute solution that lets you have it your way with\n> no changes to git, though.\n\nThanks to Jeff, I'll try it.\n\n>\n> Of course, this does open up the question of how to do any global UI\n> design at all if a decision made once gets locked in forever.\n\n100% agree, there is such question.\n\n> The reason git is hard for new users is that its UI is crazy and\n> confusing, but a major reason it keeps gaining in popularity is that\n> once you learn git, you stick with it, because you don't have to\n> relearn it with every new version.\n\nI just didn't realize that this can be such a drastic change for users\nas well as technical difficulties related to the emacs and similar\neditors.\n\nThanks,\nEugene\n"},{"id":"133513","messageId":"32541b131002031154o2146aa05k1065f7bb2d4139dc@mail.gmail.com","threadId":"22494","inReplyTo":"76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com","subject":"Re: [BUG] - \"git commit --amend\" commits, when exiting the editor with no changes written","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-03T19:54:04Z","receivedAt":"2010-02-03T19:54:04Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Feb 3, 2010 at 2:27 PM, Eugene Sajine wrote:\n>> To reiterate what I said earlier: the mtime idea isn't even\n>> automatically a bad one.  It's about as good as what currently exists,\n>> and the resulting rule (file content or mtime must be modified) is\n>> just as consistent as the current rule (file must be nonempty).  It's\n>> also arguably easier for new users to understand.\n>\n> OK. Agree on that.\n>\n>> But you can't just blindly change the system to always work in a\n>> different way.  People depend on the current behaviour.\n>\n> I understand that pretty well. My logic is that the most used command\n> which is affecting the three is \"git commit\", therefore this command\n> workflow is pretty natural for all users, but the workflow of commit\n> --amend and rebase -i which are also affecting the three is\n> inconsistent with commit. The user interaction is not the same.\n\nYou can't agree with my first statement above and yet still call the\ncommit --amend behaviour inconsistent with normal commit behaviour.\nIt is 100% consistent, as others have already pointed out. Whether it\nis consistent is not the problem. Your insistence on that point is\nwhat's making people argue with you and is undermining your real\npoint.\n\nHave fun,\n\nAvery\n"}]}