git commits unstaged files

git commits unstaged files

[Khurshid, Beenish]

Hi,

I 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.

Steps to reproduce:
1. Create unstaged changes
2. Use add -p to add some of those changes
3. Use git commit to commit the staged changes

Expectation: Only added chunks are committed.

Result:
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)
2. All unstaged changes and files are committed.
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.
4. Even after restarting git bash, the behaviour persists.
5. The same behaviour occurs when adding and committing a file, while leaving other files unstaged, when using Git GUI instead of Git Bash 

Environment:
Git version 2.12.2.windows.2
Windows 10 enterprise
Hooks: commit-msg, and pre-commit
Changes were being committed, reset, and rebased prior to this add -p attempt

If 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.

Any help or thoughts would be appreciated!

Kind Regards,
Beenish Khurshid, E.I.T I Applications Engineer
ANT Wireless | 124 - 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1
P: 587.493.4156 | F: 403.932.6521


 

Re: git commits unstaged files

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Hi Beenish,

On Thu, 17 Jan 2019, Khurshid, Beenish wrote:

> I 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.
> 
> Steps to reproduce:
> 1. Create unstaged changes
> 2. Use add -p to add some of those changes
> 3. Use git commit to commit the staged changes
> 
> Expectation: Only added chunks are committed.
> 
> Result:
> 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)
> 2. All unstaged changes and files are committed.
> 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.
> 4. Even after restarting git bash, the behaviour persists.
> 5. The same behaviour occurs when adding and committing a file, while leaving other files unstaged, when using Git GUI instead of Git Bash 
> 
> Environment:
> Git version 2.12.2.windows.2

That's almost two years old. We're at v2.20.1.windows.1 now.

> Windows 10 enterprise
> Hooks: commit-msg, and pre-commit
> Changes were being committed, reset, and rebased prior to this add -p attempt

I cannot reproduce.

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.

> If 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.

You could investigate further by setting GIT_TRACE=1 to see whether any
other Git command is run from your hooks.

In any case, if you desire help, the best way forward would be to generate
a Minimal, Complete & Verifiable Example (MCVE,
https://stackoverflow.com/help/mcve) that in particular does not require
your particular setup such as hooks, specific Git version, etc.

Ciao,
Johannes

> 
> Any help or thoughts would be appreciated!
> 
> Kind Regards,
> Beenish Khurshid, E.I.T I Applications Engineer
> ANT Wireless | 124 - 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1
> P: 587.493.4156 | F: 403.932.6521
> 
> 
>  
> 
> 
> 

RE: git commits unstaged files

[Khurshid, Beenish]

Hi Johannes,

Thanks so much for your response!

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.

Appreciate your guidance, and my sincere apologies for wasting your time on this issue!

Sincere respect for all the work you do for Git for Windows, and thus software devs the world over.

Kind Regards,
Beenish

-----Original Message-----
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Sent: January 18, 2019 3:33 AM
To: Khurshid, Beenish <Beenish.Khurshid@thisisant.com>
Cc: git@vger.kernel.org
Subject: Re: git commits unstaged files

Hi Beenish,

On Thu, 17 Jan 2019, Khurshid, Beenish wrote:

> I 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.
>
> Steps to reproduce:
> 1. Create unstaged changes
> 2. Use add -p to add some of those changes 3. Use git commit to commit
> the staged changes
>
> Expectation: Only added chunks are committed.
>
> Result:
> 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) 2. All unstaged changes and files are committed.
> 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.
> 4. Even after restarting git bash, the behaviour persists.
> 5. The same behaviour occurs when adding and committing a file, while
> leaving other files unstaged, when using Git GUI instead of Git Bash
>
> Environment:
> Git version 2.12.2.windows.2

That's almost two years old. We're at v2.20.1.windows.1 now.

> Windows 10 enterprise
> Hooks: commit-msg, and pre-commit
> Changes were being committed, reset, and rebased prior to this add -p
> attempt

I cannot reproduce.

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.

> If 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.

You could investigate further by setting GIT_TRACE=1 to see whether any other Git command is run from your hooks.

In any case, if you desire help, the best way forward would be to generate a Minimal, Complete & Verifiable Example (MCVE,
https://stackoverflow.com/help/mcve) that in particular does not require your particular setup such as hooks, specific Git version, etc.

Ciao,
Johannes

>
> Any help or thoughts would be appreciated!
>
> Kind Regards,
> Beenish Khurshid, E.I.T I Applications Engineer ANT Wireless | 124 -
> 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1
> P: 587.493.4156 | F: 403.932.6521
>
>
>
>
>
>

________________________________

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.

RE: git commits unstaged files

[Johannes Schindelin]

Hi Beenish,

On Fri, 18 Jan 2019, Khurshid, Beenish wrote:

> Thanks so much for your response!
> 
> 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.

Excellent!

> Appreciate your guidance, and my sincere apologies for wasting your time on this issue!

No need to apologize: you did the right thing by writing up a detailed bug
report (even if it turned out to miss one crucial detail, the pre-commit
hook). That is so much better than what I often deal with. Would you
believe that some users are under the impression that Twitter is a
perfectly fine medium to report bugs [*1*]?

> Sincere respect for all the work you do for Git for Windows, and thus software devs the world over.

Thank you for that lovely note. It means a lot to me.

Ciao,
Johannes

Footnote *1*: https://twitter.com/jessfraz/status/765016243854192641

> Kind Regards,
> Beenish
> 
> -----Original Message-----
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Sent: January 18, 2019 3:33 AM
> To: Khurshid, Beenish <Beenish.Khurshid@thisisant.com>
> Cc: git@vger.kernel.org
> Subject: Re: git commits unstaged files
> 
> Hi Beenish,
> 
> On Thu, 17 Jan 2019, Khurshid, Beenish wrote:
> 
> > I 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.
> >
> > Steps to reproduce:
> > 1. Create unstaged changes
> > 2. Use add -p to add some of those changes 3. Use git commit to commit
> > the staged changes
> >
> > Expectation: Only added chunks are committed.
> >
> > Result:
> > 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) 2. All unstaged changes and files are committed.
> > 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.
> > 4. Even after restarting git bash, the behaviour persists.
> > 5. The same behaviour occurs when adding and committing a file, while
> > leaving other files unstaged, when using Git GUI instead of Git Bash
> >
> > Environment:
> > Git version 2.12.2.windows.2
> 
> That's almost two years old. We're at v2.20.1.windows.1 now.
> 
> > Windows 10 enterprise
> > Hooks: commit-msg, and pre-commit
> > Changes were being committed, reset, and rebased prior to this add -p
> > attempt
> 
> I cannot reproduce.
> 
> 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.
> 
> > If 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.
> 
> You could investigate further by setting GIT_TRACE=1 to see whether any other Git command is run from your hooks.
> 
> In any case, if you desire help, the best way forward would be to generate a Minimal, Complete & Verifiable Example (MCVE,
> https://stackoverflow.com/help/mcve) that in particular does not require your particular setup such as hooks, specific Git version, etc.
> 
> Ciao,
> Johannes
> 
> >
> > Any help or thoughts would be appreciated!
> >
> > Kind Regards,
> > Beenish Khurshid, E.I.T I Applications Engineer ANT Wireless | 124 -
> > 30 Bow Street Common, Cochrane, AB, Canada T4C 2N1
> > P: 587.493.4156 | F: 403.932.6521
> >
> >
> >
> >
> >
> >
> 
> ________________________________
> 
> 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.
>