{"thread":{"id":"45490","subject":"report on a possible bug: git commit -p myfile.py unexpected output","startedAt":"2017-03-24T10:28:09Z","lastAt":"2017-03-24T15:53:10Z","messageCount":5,"participants":["Joan Aguilar","Michael J Gruber","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"315232","messageId":"CAG+Y4s8m2MqA0yAiZFzv2bAx7g5xktNRb=S-Ej0tvMwU-Un0Og@mail.gmail.com","threadId":"45490","inReplyTo":null,"subject":"report on a possible bug: git commit -p myfile.py unexpected output","fromName":"Joan Aguilar","fromEmail":"joan.aguilar.lorente@gmail.com","sentAt":"2017-03-24T10:27:20Z","receivedAt":"2017-03-24T10:28:09Z","isPatch":false,"sender":{"key":"joan.aguilar.lorente@gmail.com","avatar":null},"body":"Hello there\n\nthis is the first bug report of my life and I am not a native English\nspeaker so, first of all, I would like to apologize for my English\nskills and the report itself (if it is not precise enough).\n\nI have already read this 'guidelines'\nhttp://www.chiark.greenend.org.uk/~sgtatham/bugs.html and I will try\nto attach to them as much as I can.\n\nWhat System I am running:\n* Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux\n* git version 2.11.0. Well actually, according to the apt-get install\noutput (of course after apt-get update) -> git is already the newest\nversion (1:2.11.0-2).\n* VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 13 2017 00:56:16)\nIncluded patches: 1-197, 322\n\nWhat happened:\nI was working on my git repository yesterday and did a lot of changes\nin the file myfile.py. After a little bit of testing I was ready to\ncommit them. I decided not to commit all of them at once (because\nthese are non related changes), but instead I decided to use the -p\noption (as I always do in this case). For the first patch I decided to\ncommit only all methods I have removed because these are not needed\nanymore. So my Idea was to jump from hunk to hunk and split them\n(using 's') to select (with 'y') only the parts I wanted to commit,\nie, lines I had removed because they are not useful for me anymore. So\nI went for it and I did:\n\ngit commit -p myfile.py\n\nUntil this point all went as expected. The first hunk was printed in\nthe console and the it waited for my decision. As always. After a\ncouple of hunks I realized it was not possible to split all of them in\na proper way (to select only removed lines) because new methods were\nmixed up with the old ones. So I cancel the process (ctrl + c) and\nstarted again using 'e' instead to manually edit the hunks.\n\nSo I repeated the last command: git commit -p myfile.py but this time\nI only used 'y', 'n' and 'e'. All in all I edited ('e') two big hunks.\nBy doing this, the default editor (vim in my case) opened showing the\nhunk and with the instructions in how to edit at the bottom.\nEverything as used to be. Until this point all went as I expected.\n\nIn the two hunk I edited I did the same. I removed all + lines by\ndeleting them and I make some - lines as context. Like explained in\nthe bottom of the file.\n\nWhen I was done with each of the hunks, I saved and closed the editor.\nNo error was produced (I sometimes make mistakes while editing a hunk\nand know you can get an error (patch does not apply) here, but in this\ncase were no errors there so the next hunk was printed and the commit\nprocedure kept going.\n\nWhen I was done with all hunks, the editor (vim) started again to\nwrite the commit message. I wrote (something like) this:\n\n    myfile.py -> old unused methods removed...\n\n    1) mymethod1\n    2) mymethod2\n    3) mymethod3\n    4) mymethod4\n    5) mymethod5\n\nYes, not the best commit ever ;) but enough for us in this case.\nAnyway, I saved it and close the editor and I was surprised by the git\noutput.\n\n[master 96d1c24] myfile.py -> old unused methods removed...\n 1 file changed, 182 insertions(+), 302 deletions(-)\n rewrite myfile.py (60%)\n\nWhat?? I thought to myself... Insertions?? This can't be true? I\nremoved all + lines, my idea was to commit only deletions... What did\nI wrong?\n\nTo check this I did\n* git show 96d1c24\nand I saw only red minus lines , ie, deletions. As I expected.\n\nTo check it twice I used tig too.\n\ntig showed the same for this specific commit\nmyfile.py | 120\n---------------------------------------------------------------------------------------------------------------------\n1 file changed, 120 deletions(-)\n\nConclusion:\nAfter these two checks I am sure I did what I intended to do. What I\ndo not understand is the output of git when I was done with the\ncommit.\n\nMaybe is just me, because I do not understand how git commit -p when\nusing 'e' to edit hunks works. But as user I would expect to see only\ndeletions in the output message if I am picking only deletions.\n\nIf this is a bug, I hope you can reproduce it on your system. If not,\ndo not hesitate to contact me for further information.\n\n\nKind regards,\n\nJoan Aguilar\n--\nJoan Aguilar Lorente\n"},{"id":"315252","messageId":"26915be5-8749-7f66-4d60-516e7ed60adc@grubix.eu","threadId":"45490","inReplyTo":"CAG+Y4s8m2MqA0yAiZFzv2bAx7g5xktNRb=S-Ej0tvMwU-Un0Og@mail.gmail.com","subject":"Re: report on a possible bug: git commit -p myfile.py unexpected output","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-03-24T14:59:07Z","receivedAt":"2017-03-24T14:59:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Joan Aguilar venit, vidit, dixit 24.03.2017 11:27:\n> Hello there\n> \n> this is the first bug report of my life and I am not a native English\n> speaker so, first of all, I would like to apologize for my English\n> skills and the report itself (if it is not precise enough).\n> \n> I have already read this 'guidelines'\n> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and I will try\n> to attach to them as much as I can.\n> \n> What System I am running:\n> * Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux\n> * git version 2.11.0. Well actually, according to the apt-get install\n> output (of course after apt-get update) -> git is already the newest\n> version (1:2.11.0-2).\n> * VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Feb 13 2017 00:56:16)\n> Included patches: 1-197, 322\n> \n> What happened:\n> I was working on my git repository yesterday and did a lot of changes\n> in the file myfile.py. After a little bit of testing I was ready to\n> commit them. I decided not to commit all of them at once (because\n> these are non related changes), but instead I decided to use the -p\n> option (as I always do in this case). For the first patch I decided to\n> commit only all methods I have removed because these are not needed\n> anymore. So my Idea was to jump from hunk to hunk and split them\n> (using 's') to select (with 'y') only the parts I wanted to commit,\n> ie, lines I had removed because they are not useful for me anymore. So\n> I went for it and I did:\n> \n> git commit -p myfile.py\n> \n> Until this point all went as expected. The first hunk was printed in\n> the console and the it waited for my decision. As always. After a\n> couple of hunks I realized it was not possible to split all of them in\n> a proper way (to select only removed lines) because new methods were\n> mixed up with the old ones. So I cancel the process (ctrl + c) and\n> started again using 'e' instead to manually edit the hunks.\n> \n> So I repeated the last command: git commit -p myfile.py but this time\n> I only used 'y', 'n' and 'e'. All in all I edited ('e') two big hunks.\n> By doing this, the default editor (vim in my case) opened showing the\n> hunk and with the instructions in how to edit at the bottom.\n> Everything as used to be. Until this point all went as I expected.\n> \n> In the two hunk I edited I did the same. I removed all + lines by\n> deleting them and I make some - lines as context. Like explained in\n> the bottom of the file.\n> \n> When I was done with each of the hunks, I saved and closed the editor.\n> No error was produced (I sometimes make mistakes while editing a hunk\n> and know you can get an error (patch does not apply) here, but in this\n> case were no errors there so the next hunk was printed and the commit\n> procedure kept going.\n> \n> When I was done with all hunks, the editor (vim) started again to\n> write the commit message. I wrote (something like) this:\n> \n>     myfile.py -> old unused methods removed...\n> \n>     1) mymethod1\n>     2) mymethod2\n>     3) mymethod3\n>     4) mymethod4\n>     5) mymethod5\n> \n> Yes, not the best commit ever ;) but enough for us in this case.\n> Anyway, I saved it and close the editor and I was surprised by the git\n> output.\n> \n> [master 96d1c24] myfile.py -> old unused methods removed...\n>  1 file changed, 182 insertions(+), 302 deletions(-)\n>  rewrite myfile.py (60%)\n> \n> What?? I thought to myself... Insertions?? This can't be true? I\n> removed all + lines, my idea was to commit only deletions... What did\n> I wrong?\n> \n> To check this I did\n> * git show 96d1c24\n> and I saw only red minus lines , ie, deletions. As I expected.\n\nWhat dows \"git show --stat\" say?\n\n> To check it twice I used tig too.\n> \n> tig showed the same for this specific commit\n> myfile.py | 120\n> ---------------------------------------------------------------------------------------------------------------------\n> 1 file changed, 120 deletions(-)\n> \n> Conclusion:\n> After these two checks I am sure I did what I intended to do. What I\n> do not understand is the output of git when I was done with the\n> commit.\n> \n> Maybe is just me, because I do not understand how git commit -p when\n> using 'e' to edit hunks works. But as user I would expect to see only\n> deletions in the output message if I am picking only deletions.\n> \n> If this is a bug, I hope you can reproduce it on your system. If not,\n> do not hesitate to contact me for further information.\n> \n> \n> Kind regards,\n> \n> Joan Aguilar\n> --\n> Joan Aguilar Lorente\n> \n\n182-302 = -120\n\nDid you make any changes in the lines that you left? Apparantly, that's\nwhat the rewrite looked like to git commit.\n\nMichael\n"},{"id":"315254","messageId":"20170324150921.vwh4yqpz25ph3zxe@sigill.intra.peff.net","threadId":"45490","inReplyTo":"26915be5-8749-7f66-4d60-516e7ed60adc@grubix.eu","subject":"Re: report on a possible bug: git commit -p myfile.py unexpected output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-24T15:09:21Z","receivedAt":"2017-03-24T15:09:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 24, 2017 at 03:59:07PM +0100, Michael J Gruber wrote:\n\n> > [master 96d1c24] myfile.py -> old unused methods removed...\n> >  1 file changed, 182 insertions(+), 302 deletions(-)\n> >  rewrite myfile.py (60%)\n> [...]\n> > myfile.py | 120\n> > ---------------------------------------------------------------------------------------------------------------------\n> > 1 file changed, 120 deletions(-)\n> \n> 182-302 = -120\n> \n> Did you make any changes in the lines that you left? Apparantly, that's\n> what the rewrite looked like to git commit.\n\nEven without changes to the remaining lines, a rewrite diff would\nconsider them removed from the preimage and added again in the\npost-image.\n\nThe difference between the two commands is that \"commit\" turns on \"-B\"\nbreak detection by default, and \"git show\", \"tig\", etc, do not.\n\nLooking at the actual diff with \"git show -B\" should show something\nlike:\n\n  -old\n  -lines\n  -that\n  -weren't\n  -touched\n  -some\n  -lines\n  -that\n  -were\n  -deleted\n  +old\n  +lines\n  +that\n  +weren't\n  +touched\n\nThe change is the same no matter how you view it; the \"-B\" flag just\nasks Git to show a non-minimal diff when the file was substantially\nchanged.\n\n-Peff\n"},{"id":"315262","messageId":"CAG+Y4s8WGwmP7uOsNz4GkR3tsaeB2e1qBysrs-4pqLBKYC+Grg@mail.gmail.com","threadId":"45490","inReplyTo":"20170324150921.vwh4yqpz25ph3zxe@sigill.intra.peff.net","subject":"Re: report on a possible bug: git commit -p myfile.py unexpected output","fromName":"Joan Aguilar","fromEmail":"joan.aguilar.lorente@gmail.com","sentAt":"2017-03-24T15:31:09Z","receivedAt":"2017-03-24T15:31:56Z","isPatch":false,"sender":{"key":"joan.aguilar.lorente@gmail.com","avatar":null},"body":"Hello Michael, hello Jeff,\n\nI was writing a response to Michael and I received the Email from\nJeff, so I decided to reply to the second one, with copy to both of\nyou (and the mailing list too, of course). I hope this is ok for you.\n\nIt works exactly as Jeff said.\n\nIf I do git show --stat 96d1c24 the output is:\nuser@machine:~/mygitrepo$ git show --stat 96d1c24\ncommit 96d1c24*******\nAuthor: Joan Aguilar Lorente <joan.aguilar.lorente@gmail.com>\nDate:   Thu Mar 23 18:15:07 2017 +0100\n\n    myfile.py -> old unused methods removed...\n\n    1) mymethod1\n    2) mymethod2\n    3) mymethod3\n    4) mymethod4\n    5) mymethod5\n\n myfile.py | 120\n------------------------------------------------------------------------------------------------------------------------\n 1 file changed, 120 deletions(-)\n\nBut if I add the flag -B (git show --stat -B 96d1c24) the last two\nlines are different (as already expected by Jeff) and match exactly\nthe output of git commit I got yesterday.\n myfile.py | 484\n++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------------------------------------------------------------------------------------------------\n 1 file changed, 182 insertions(+), 302 deletions(-)\n\nThe output of git show -B is, of course, like the one expected by Jeff too.\n\nThank you! I learned a little bit about git. And most of all, I\nrealize there are a lot of options and flags I am not aware of, and\nnot using at all! I have to read the documentation. I am missing a lot\nof git!!\n\nI am sorry that I reported this as possible bug. I guess I was just\nconfused because the \"standard behavior\" of \"git commit\" differs from\nthe one of \"tig\" or \"git show\".\n\nThank you again and I see you around.\n\nBest regards\nJoan Aguilar Lorente\n--\nJoan Aguilar Lorente\n\n\nOn Fri, Mar 24, 2017 at 4:09 PM, Jeff King <peff@peff.net> wrote:\n> On Fri, Mar 24, 2017 at 03:59:07PM +0100, Michael J Gruber wrote:\n>\n>> > [master 96d1c24] myfile.py -> old unused methods removed...\n>> >  1 file changed, 182 insertions(+), 302 deletions(-)\n>> >  rewrite myfile.py (60%)\n>> [...]\n>> > myfile.py | 120\n>> > ---------------------------------------------------------------------------------------------------------------------\n>> > 1 file changed, 120 deletions(-)\n>>\n>> 182-302 = -120\n>>\n>> Did you make any changes in the lines that you left? Apparantly, that's\n>> what the rewrite looked like to git commit.\n>\n> Even without changes to the remaining lines, a rewrite diff would\n> consider them removed from the preimage and added again in the\n> post-image.\n>\n> The difference between the two commands is that \"commit\" turns on \"-B\"\n> break detection by default, and \"git show\", \"tig\", etc, do not.\n>\n> Looking at the actual diff with \"git show -B\" should show something\n> like:\n>\n>   -old\n>   -lines\n>   -that\n>   -weren't\n>   -touched\n>   -some\n>   -lines\n>   -that\n>   -were\n>   -deleted\n>   +old\n>   +lines\n>   +that\n>   +weren't\n>   +touched\n>\n> The change is the same no matter how you view it; the \"-B\" flag just\n> asks Git to show a non-minimal diff when the file was substantially\n> changed.\n>\n> -Peff\n"},{"id":"315265","messageId":"20170324155229.jw7auwikq6gig7cv@sigill.intra.peff.net","threadId":"45490","inReplyTo":"CAG+Y4s8WGwmP7uOsNz4GkR3tsaeB2e1qBysrs-4pqLBKYC+Grg@mail.gmail.com","subject":"Re: report on a possible bug: git commit -p myfile.py unexpected output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-24T15:52:29Z","receivedAt":"2017-03-24T15:53:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 24, 2017 at 04:31:09PM +0100, Joan Aguilar wrote:\n\n> Thank you! I learned a little bit about git. And most of all, I\n> realize there are a lot of options and flags I am not aware of, and\n> not using at all! I have to read the documentation. I am missing a lot\n> of git!!\n> \n> I am sorry that I reported this as possible bug. I guess I was just\n> confused because the \"standard behavior\" of \"git commit\" differs from\n> the one of \"tig\" or \"git show\".\n\nNo problem. Thanks for a thorough report; it was easy to see what the\nproblem was from reading it.\n\n-Peff\n"}]}