BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Andrew Thorp]

Hello all,

As described in the subject line, it seems like git commit is
committing entire files when chunks of the files are staged using `git
add -p`, in spite of leaving chunks out of the stage. See below for
the bug-report template questionnaire. Please let me know if there is
anything I can do to help resolve this issue or if there is anything
needed.

Thanks,

Andrew Thorp


> What did you do before the bug happened? (Steps to reproduce your issue)

Edit a checked-in file, adding multiple chunks of lines to the file.
Using `git add -p <file>`, stage one of the chunks, leave some chunks unstaged.
After running `git status` the file should both in the section
`Changes to be committed:` and `Changes not staged for commit`.
Commit the changes.

> What did you expect to happen? (Expected behavior)

I expected all staged changes to be committed and unstaged changes to
remain unstaged.

> What happened instead? (Actual behavior)

The entire file was committed, including the unstaged chunks of changes.

> What's different between what you expected and what actually happened?

It appears as though the remaining file lines were both checked in and
committed, when only the later should have happened.

[System Info]
git version:
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:47
PDT 2021; root:xnu-7195.101.2~1/RELEASE_X86_64 x86_64
compiler info: clang: 12.0.5 (clang-1205.0.22.9)
libc info: no libc information available
$SHELL (typically, interactive shell): /bin/zsh

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Junio C Hamano]

Andrew Thorp <andrew.thorp.dev@gmail.com> writes:

>> What did you do before the bug happened? (Steps to reproduce your issue)
>
> Edit a checked-in file, adding multiple chunks of lines to the file.
> Using `git add -p <file>`, stage one of the chunks, leave some chunks unstaged.
> After running `git status` the file should both in the section
> `Changes to be committed:` and `Changes not staged for commit`.
> Commit the changes.

How was the last "commit the changes" done exactly?  

If either "git commit -a" or "git commit <file>" was done, that
would explain the symptom of having the entire up-to-date contents
of <file> in the working tree recorded in the resulting commit.  The
former tells "take all changes in the working tree", the latter
tells "take the version of <file> in the working tree as a whole",
to Git to create a commit out of.

"git commit" without pathspec would have made a partial commit that
records only the changes that were added with "git add -p" to the
index, though.

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Andrew Thorp]

> How was the last "commit the changes" done exactly?

So far I have confirmed this error occurs when running `git commit -m "foo"`,
`git commit`, and `git commit --amend`.

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Andrew Thorp]

> git commit" without pathspec would have made a partial commit that
records only the changes that were added with "git add -p" to the
index, though.

Yeah, that was the expected behavior, but not what I experienced.

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Junio C Hamano]

Andrew Thorp <andrew.thorp.dev@gmail.com> writes:

>> git commit" without pathspec would have made a partial commit that
> records only the changes that were added with "git add -p" to the
> index, though.
>
> Yeah, that was the expected behavior, but not what I experienced.

Sorry but it does not reproduce for me.

Here is my "reproduction recipe", designed to be followable by
anybody who has a copy of git and this piece of e-mail without
referencing anything else.

$ edit Makefile ; git diff Makefile
diff --git i/Makefile w/Makefile
index 9573190f1d..6bf8f3147b 100644
--- i/Makefile
+++ w/Makefile
@@ -1,4 +1,4 @@
-# The default target of this Makefile is...
+# The default target of this Makefile is.....
 all::
 
 # Define V=1 to have a more verbose compile.
@@ -30,7 +30,7 @@ all::
 # Define USE_LIBPCRE if you have and want to use libpcre. Various
 # commands such as log and grep offer runtime options to use
 # Perl-compatible regular expressions instead of standard or extended
-# POSIX regular expressions.
+# POSIX regular expressions...
 #
 # Only libpcre version 2 is supported. USE_LIBPCRE2 is a synonym for
 # USE_LIBPCRE, support for the old USE_LIBPCRE1 has been removed.

... You can see that we have two changes to a single file now ...

$ printf "y\nn\n" | git add -p >/dev/null
$ git status -uno
On branch test
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   Makefile

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Makefile

Untracked files not listed (use -u option to show untracked files)

... And tell "add -p" to add the first but not the second hunk.

$ git commit -m test

... And commit.

$ git status -uno
On branch test
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Makefile

no changes added to commit (use "git add" and/or "git commit -a")

... Then the working tree file stays dirty because the second hunk
was not added.

$ git diff
diff --git i/Makefile w/Makefile
index fe6d649c27..6bf8f3147b 100644
--- i/Makefile
+++ w/Makefile
@@ -30,7 +30,7 @@ all::
 # Define USE_LIBPCRE if you have and want to use libpcre. Various
 # commands such as log and grep offer runtime options to use
 # Perl-compatible regular expressions instead of standard or extended
-# POSIX regular expressions.
+# POSIX regular expressions...
 #
 # Only libpcre version 2 is supported. USE_LIBPCRE2 is a synonym for
 # USE_LIBPCRE, support for the old USE_LIBPCRE1 has been removed.

... just as we can see here.  Of course, the first hunk is in the
commit, as can be seen ehre

$ git diff HEAD^ HEAD
diff --git a/Makefile b/Makefile
index 9573190f1d..fe6d649c27 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-# The default target of this Makefile is...
+# The default target of this Makefile is.....
 all::
 
 # Define V=1 to have a more verbose compile.

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Andrew Thorp]

Ah, you're right. I have a pre-commit hook which does some formatting and
then re-adds the files. Doing so adds the unstaged chunks silently.

Thanks for taking a look Junio. I'll try to reproduce on a clean repo next time.

Cheers,

Andrew Thorp

Re: BUG: `git commit` adding unstaged chunks of files to commits on 2.33.0

[Philippe Blain]

Hi Andrew,

Le 2021-08-31 à 13:15, Andrew Thorp a écrit :
> Hello all,
> 
>
> 
> [System Info]
> git version:
> git version 2.33.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:47
> PDT 2021; root:xnu-7195.101.2~1/RELEASE_X86_64 x86_64
> compiler info: clang: 12.0.5 (clang-1205.0.22.9)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /bin/zsh
> 

As I read downthread, the behaviour was due to your pre-commit hook.

Normally below the "System Info" section in the 'git bugreport' template
there should be an "Enabled Hooks" section, which does not appear above.
I would be curious to know why; I'm guessing you ran 'git bugreport' from
outside your repo and so it said:

[Enabled Hooks]
not run from a git repository - no hooks to show

and you deleted that section ?

I'm thinking that maybe if the 'git bugreport' template mentioned upfront that the
command should be run in the repo where you observed a bug, maybe it would lead to
fewer back and forth like in this thread ? (CC'ing Emily who implemented 'git bugreport').

I've sent a PR [1] for the web site so that this is also mentioned at https://git-scm.com/community.

Cheers,
Philippe.

[1] https://github.com/git/git-scm.com/pull/1629