{"thread":{"id":"50254","subject":"git commits unstaged files","startedAt":"2019-01-17T20:58:22Z","lastAt":"2019-01-21T14:53:19Z","messageCount":4,"participants":["Khurshid, Beenish","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"367030","messageId":"19f764a20b384e099372921d76ec4f73@thisisant.com","threadId":"50254","inReplyTo":null,"subject":"git commits unstaged files","fromName":"Khurshid, Beenish","fromEmail":"beenish.khurshid@thisisant.com","sentAt":"2019-01-17T20:57:59Z","receivedAt":"2019-01-17T20:58:22Z","isPatch":false,"sender":{"key":"beenish.khurshid@thisisant.com","avatar":null},"body":"Hi,\n\nI frequently use 'git add -p' to filter changes before committing. This usually works, but on many occasions, the use of add and commit results in unstaged chunks and files being committed.\n\nSteps to reproduce:\n1. Create unstaged changes\n2. Use add -p to add some of those changes\n3. Use git commit to commit the staged changes\n\nExpectation: Only added chunks are committed.\n\nResult:\n1. When editing the commit message, the added files appear staged in the comments at the end of the commit message, and the unstage files appear unstaged. (expected behaviour)\n2. All unstaged changes and files are committed.\n3. Once git enters this state, even git add produces the same result: Using git add to only add some files (and not chunks), and subsequently committing, results in unstaged files also being committed.\n4. Even after restarting git bash, the behaviour persists.\n5. The same behaviour occurs when adding and committing a file, while leaving other files unstaged, when using Git GUI instead of Git Bash \n\nEnvironment:\nGit version 2.12.2.windows.2\nWindows 10 enterprise\nHooks: commit-msg, and pre-commit\nChanges were being committed, reset, and rebased prior to this add -p attempt\n\nIf more information is needed, please do not hesitate to contact me. Since this is a significant part of my workflow, the failure of the command to work in the expected way is fairly disruptive to my workflow.\n\nAny help or thoughts would be appreciated!\n\nKind Regards,\nBeenish Khurshid, E.I.T I Applications Engineer\nANT Wireless | 124 - 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1\nP: 587.493.4156 | F: 403.932.6521\n\n\n \n\n\n"},{"id":"367079","messageId":"nycvar.QRO.7.76.6.1901181129310.41@tvgsbejvaqbjf.bet","threadId":"50254","inReplyTo":"19f764a20b384e099372921d76ec4f73@thisisant.com","subject":"Re: git commits unstaged files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-18T10:32:58Z","receivedAt":"2019-01-18T10:33:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Beenish,\n\nOn Thu, 17 Jan 2019, Khurshid, Beenish wrote:\n\n> I frequently use 'git add -p' to filter changes before committing. This\n> usually works, but on many occasions, the use of add and commit results\n> in unstaged chunks and files being committed.\n> \n> Steps to reproduce:\n> 1. Create unstaged changes\n> 2. Use add -p to add some of those changes\n> 3. Use git commit to commit the staged changes\n> \n> Expectation: Only added chunks are committed.\n> \n> Result:\n> 1. When editing the commit message, the added files appear staged in the comments at the end of the commit message, and the unstage files appear unstaged. (expected behaviour)\n> 2. All unstaged changes and files are committed.\n> 3. Once git enters this state, even git add produces the same result: Using git add to only add some files (and not chunks), and subsequently committing, results in unstaged files also being committed.\n> 4. Even after restarting git bash, the behaviour persists.\n> 5. The same behaviour occurs when adding and committing a file, while leaving other files unstaged, when using Git GUI instead of Git Bash \n> \n> Environment:\n> Git version 2.12.2.windows.2\n\nThat's almost two years old. We're at v2.20.1.windows.1 now.\n\n> Windows 10 enterprise\n> Hooks: commit-msg, and pre-commit\n> Changes were being committed, reset, and rebased prior to this add -p attempt\n\nI cannot reproduce.\n\nFWIW I sometimes have the same problem, but in all those cases the problem\nis my muscle memory that makes me add the `-a` option to `git commit`\nbefore I can stop myself.\n\n> If more information is needed, please do not hesitate to contact me.\n> Since this is a significant part of my workflow, the failure of the\n> command to work in the expected way is fairly disruptive to my workflow.\n\nYou could investigate further by setting GIT_TRACE=1 to see whether any\nother Git command is run from your hooks.\n\nIn any case, if you desire help, the best way forward would be to generate\na Minimal, Complete & Verifiable Example (MCVE,\nhttps://stackoverflow.com/help/mcve) that in particular does not require\nyour particular setup such as hooks, specific Git version, etc.\n\nCiao,\nJohannes\n\n> \n> Any help or thoughts would be appreciated!\n> \n> Kind Regards,\n> Beenish Khurshid, E.I.T I Applications Engineer\n> ANT Wireless | 124 - 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1\n> P: 587.493.4156 | F: 403.932.6521\n> \n> \n>  \n> \n> \n> "},{"id":"367132","messageId":"738f3d692f534c21af34256f391744b4@thisisant.com","threadId":"50254","inReplyTo":"nycvar.QRO.7.76.6.1901181129310.41@tvgsbejvaqbjf.bet","subject":"RE: git commits unstaged files","fromName":"Khurshid, Beenish","fromEmail":"beenish.khurshid@thisisant.com","sentAt":"2019-01-18T19:03:38Z","receivedAt":"2019-01-18T19:03:48Z","isPatch":false,"sender":{"key":"beenish.khurshid@thisisant.com","avatar":null},"body":"Hi Johannes,\n\nThanks so much for your response!\n\nAs I went down the path of trying to prove the problem via an MCVE, and found that the problem was not reproducing as I was expecting, I found out that one of the pre-commit hooks had a bug for a corner case that I regularly traverse, and that the bug had been fixed in an updated version of the hook.\n\nAppreciate your guidance, and my sincere apologies for wasting your time on this issue!\n\nSincere respect for all the work you do for Git for Windows, and thus software devs the world over.\n\nKind Regards,\nBeenish\n\n-----Original Message-----\nFrom: Johannes Schindelin <Johannes.Schindelin@gmx.de>\nSent: January 18, 2019 3:33 AM\nTo: Khurshid, Beenish <Beenish.Khurshid@thisisant.com>\nCc: git@vger.kernel.org\nSubject: Re: git commits unstaged files\n\nHi Beenish,\n\nOn Thu, 17 Jan 2019, Khurshid, Beenish wrote:\n\n> I frequently use 'git add -p' to filter changes before committing.\n> This usually works, but on many occasions, the use of add and commit\n> results in unstaged chunks and files being committed.\n>\n> Steps to reproduce:\n> 1. Create unstaged changes\n> 2. Use add -p to add some of those changes 3. Use git commit to commit\n> the staged changes\n>\n> Expectation: Only added chunks are committed.\n>\n> Result:\n> 1. When editing the commit message, the added files appear staged in\n> the comments at the end of the commit message, and the unstage files appear unstaged. (expected behaviour) 2. All unstaged changes and files are committed.\n> 3. Once git enters this state, even git add produces the same result: Using git add to only add some files (and not chunks), and subsequently committing, results in unstaged files also being committed.\n> 4. Even after restarting git bash, the behaviour persists.\n> 5. The same behaviour occurs when adding and committing a file, while\n> leaving other files unstaged, when using Git GUI instead of Git Bash\n>\n> Environment:\n> Git version 2.12.2.windows.2\n\nThat's almost two years old. We're at v2.20.1.windows.1 now.\n\n> Windows 10 enterprise\n> Hooks: commit-msg, and pre-commit\n> Changes were being committed, reset, and rebased prior to this add -p\n> attempt\n\nI cannot reproduce.\n\nFWIW I sometimes have the same problem, but in all those cases the problem is my muscle memory that makes me add the `-a` option to `git commit` before I can stop myself.\n\n> If more information is needed, please do not hesitate to contact me.\n> Since this is a significant part of my workflow, the failure of the\n> command to work in the expected way is fairly disruptive to my workflow.\n\nYou could investigate further by setting GIT_TRACE=1 to see whether any other Git command is run from your hooks.\n\nIn any case, if you desire help, the best way forward would be to generate a Minimal, Complete & Verifiable Example (MCVE,\nhttps://stackoverflow.com/help/mcve) that in particular does not require your particular setup such as hooks, specific Git version, etc.\n\nCiao,\nJohannes\n\n>\n> Any help or thoughts would be appreciated!\n>\n> Kind Regards,\n> Beenish Khurshid, E.I.T I Applications Engineer ANT Wireless | 124 -\n> 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1\n> P: 587.493.4156 | F: 403.932.6521\n>\n>\n>\n>\n>\n>\n\n________________________________\n\nCONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.\n"},{"id":"367235","messageId":"nycvar.QRO.7.76.6.1901211535321.41@tvgsbejvaqbjf.bet","threadId":"50254","inReplyTo":"738f3d692f534c21af34256f391744b4@thisisant.com","subject":"RE: git commits unstaged files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-01-21T14:52:56Z","receivedAt":"2019-01-21T14:53:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Beenish,\n\nOn Fri, 18 Jan 2019, Khurshid, Beenish wrote:\n\n> Thanks so much for your response!\n> \n> As I went down the path of trying to prove the problem via an MCVE, and found that the problem was not reproducing as I was expecting, I found out that one of the pre-commit hooks had a bug for a corner case that I regularly traverse, and that the bug had been fixed in an updated version of the hook.\n\nExcellent!\n\n> Appreciate your guidance, and my sincere apologies for wasting your time on this issue!\n\nNo need to apologize: you did the right thing by writing up a detailed bug\nreport (even if it turned out to miss one crucial detail, the pre-commit\nhook). That is so much better than what I often deal with. Would you\nbelieve that some users are under the impression that Twitter is a\nperfectly fine medium to report bugs [*1*]?\n\n> Sincere respect for all the work you do for Git for Windows, and thus software devs the world over.\n\nThank you for that lovely note. It means a lot to me.\n\nCiao,\nJohannes\n\nFootnote *1*: https://twitter.com/jessfraz/status/765016243854192641\n\n> Kind Regards,\n> Beenish\n> \n> -----Original Message-----\n> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n> Sent: January 18, 2019 3:33 AM\n> To: Khurshid, Beenish <Beenish.Khurshid@thisisant.com>\n> Cc: git@vger.kernel.org\n> Subject: Re: git commits unstaged files\n> \n> Hi Beenish,\n> \n> On Thu, 17 Jan 2019, Khurshid, Beenish wrote:\n> \n> > I frequently use 'git add -p' to filter changes before committing.\n> > This usually works, but on many occasions, the use of add and commit\n> > results in unstaged chunks and files being committed.\n> >\n> > Steps to reproduce:\n> > 1. Create unstaged changes\n> > 2. Use add -p to add some of those changes 3. Use git commit to commit\n> > the staged changes\n> >\n> > Expectation: Only added chunks are committed.\n> >\n> > Result:\n> > 1. When editing the commit message, the added files appear staged in\n> > the comments at the end of the commit message, and the unstage files appear unstaged. (expected behaviour) 2. All unstaged changes and files are committed.\n> > 3. Once git enters this state, even git add produces the same result: Using git add to only add some files (and not chunks), and subsequently committing, results in unstaged files also being committed.\n> > 4. Even after restarting git bash, the behaviour persists.\n> > 5. The same behaviour occurs when adding and committing a file, while\n> > leaving other files unstaged, when using Git GUI instead of Git Bash\n> >\n> > Environment:\n> > Git version 2.12.2.windows.2\n> \n> That's almost two years old. We're at v2.20.1.windows.1 now.\n> \n> > Windows 10 enterprise\n> > Hooks: commit-msg, and pre-commit\n> > Changes were being committed, reset, and rebased prior to this add -p\n> > attempt\n> \n> I cannot reproduce.\n> \n> FWIW I sometimes have the same problem, but in all those cases the problem is my muscle memory that makes me add the `-a` option to `git commit` before I can stop myself.\n> \n> > If more information is needed, please do not hesitate to contact me.\n> > Since this is a significant part of my workflow, the failure of the\n> > command to work in the expected way is fairly disruptive to my workflow.\n> \n> You could investigate further by setting GIT_TRACE=1 to see whether any other Git command is run from your hooks.\n> \n> In any case, if you desire help, the best way forward would be to generate a Minimal, Complete & Verifiable Example (MCVE,\n> https://stackoverflow.com/help/mcve) that in particular does not require your particular setup such as hooks, specific Git version, etc.\n> \n> Ciao,\n> Johannes\n> \n> >\n> > Any help or thoughts would be appreciated!\n> >\n> > Kind Regards,\n> > Beenish Khurshid, E.I.T I Applications Engineer ANT Wireless | 124 -\n> > 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1\n> > P: 587.493.4156 | F: 403.932.6521\n> >\n> >\n> >\n> >\n> >\n> >\n> \n> ________________________________\n> \n> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.\n> \n"}]}