threads / bug / 56418

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

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

## tl;dr

7 messages between Aug 31, 2021 and Sep 1, 2021.

replies: 6people: 3as markdown or json

Andrew Thorp· Aug 31, 2021, 17:15 UTC · lore

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

Junio C Hamano· Aug 31, 2021, 17:56 UTC · re: Andrew Thorp · lore

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

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

Show 7 quoted lines

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

Andrew Thorp· Aug 31, 2021, 18:01 UTC · re: Junio C Hamano · lore

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

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

Andrew Thorp· Aug 31, 2021, 18:01 UTC · re: Andrew Thorp · lore

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

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

Junio C Hamano· Aug 31, 2021, 19:25 UTC · re: Andrew Thorp · lore

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

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

Show 5 quoted lines

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

Andrew Thorp· Aug 31, 2021, 19:45 UTC · re: Junio C Hamano · lore

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

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

Philippe Blain· Sep 1, 2021, 14:03 UTC · re: Andrew Thorp · lore

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

Hi Andrew,

Le 2021-08-31 à 13:15, Andrew Thorp a écrit :

Show 18 quoted lines

> 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