bugreport

bugreport

[Ole M]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
* open Git Gui in a repository from git bash ($ git gui&)
* select some text in the diff pane

What did you expect to happen? (Expected behavior)
* selected text should be highlighted with white text on blue
background (maybe it used to use system defined colors?)

What happened instead? (Actual behavior)
* selected text is highlighted with white text on black background

What's different between what you expected and what actually happened?
* The contrast has increased to a level that is painful for me to look
at, making it difficult to read the selected text.
* It also makes the experience of this tool different from gitk,
making me focus on the tool rather than the content and workflow.

Anything else you want to add:


Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.29.2.windows.2
cpu: x86_64
built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
uname: Windows 10.0 18363
compiler info: gnuc: 10.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


[Enabled Hooks]

Re: bugreport

[Stefan Haller]

On 02.12.20 11:08, Ole M wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> * open Git Gui in a repository from git bash ($ git gui&)
> * select some text in the diff pane
> 
> What did you expect to happen? (Expected behavior)
> * selected text should be highlighted with white text on blue
> background (maybe it used to use system defined colors?)
> 
> What happened instead? (Actual behavior)
> * selected text is highlighted with white text on black background

Hi Ole,

thanks for the report. It's a known bug, a fix for this is already in
the works.

Best,
Stefan


> What's different between what you expected and what actually happened?
> * The contrast has increased to a level that is painful for me to look
> at, making it difficult to read the selected text.
> * It also makes the experience of this tool different from gitk,
> making me focus on the tool rather than the content and workflow.
> 
> Anything else you want to add:
> 
> 
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
> 
> 
> [System Info]
> git version:
> git version 2.29.2.windows.2
> cpu: x86_64
> built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Windows 10.0 18363
> compiler info: gnuc: 10.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
> 
> 
> [Enabled Hooks]
> 

bugreport

[galo joel]

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



[-- Attachment #1.2: Type: text/html, Size: 26 bytes --]

[-- Attachment #2: git-bugreport-2023-10-24-2215.txt --]
[-- Type: text/plain, Size: 1442 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

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

execute as admin git bash and,(in cmd W10, same. open git-bash.exe as system-32).
try chmod 755, 777... does not work 'cause im user ($) and not admin (#)

Wha did you expect to happen? (Expected behavior)

change .sh to chmod 755 for execute bash

What happened instead? (Actual behavior)

nothing ._.

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

i expected a good sript in bash. now i'm sad

Anything else you want to add:

Please tell me what happen, maybe i'm wrong but chatGPT also no have idea why 
i cannot be admin in my own laptop xD, or maybe i need some libraries that i didnot
install. I sell all my information so please help me to understand why does not work :)

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.42.0.windows.2
cpu: x86_64
built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 10.0 19045 
compiler info: gnuc: 13.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe


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

Re: bugreport

[Thomas Guyot]

Hi Joel,

I'm copying your attachment in-line for simplicity...

On 2023-10-24 16:40, galo joel wrote:
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> execute as admin git bash and,(in cmd W10, same. open git-bash.exe as system-32).
> try chmod 755, 777... does not work 'cause im user ($) and not admin (#)
>
> Wha did you expect to happen? (Expected behavior)
>
> change .sh to chmod 755 for execute bash
>
> What happened instead? (Actual behavior)
>
> nothing ._.
>
> What's different between what you expected and what actually happened?
>
> i expected a good sript in bash. now i'm sad
>
> Anything else you want to add:
>
> Please tell me what happen, maybe i'm wrong but chatGPT also no have idea why
> i cannot be admin in my own laptop xD, or maybe i need some libraries that i didnot
> install. I sell all my information so please help me to understand why does not work :)
>
> Please review the rest of the bug report below.
> You can delete any lines you don't wish to share.
>
>
> [System Info]
> git version:
> git version 2.42.0.windows.2
> cpu: x86_64
> built from commit: 2f819d1670fff9a1818f63b6722e9959405378e3
> sizeof-long: 4
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> uname: Windows 10.0 19045
> compiler info: gnuc: 13.2
> libc info: no libc information available
> $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe
>
>
> [Enabled Hooks]
> not run from a git repository - no hooks to show
>

You don't need admin to use git on Window. OTOH Windows has no concept 
of POSIX file permissions, and this is the reason you cannot set file 
permissions using chmod under git bash.

This Stackoverflow question has the answer you're most likely looking for:

https://stackoverflow.com/questions/21691202/how-to-create-file-execute-mode-permissions-in-git-on-windows

Regards,

--

Thomas

Bugreport

[Frank Schwidom]

This bug exists in possibly all git versions.

$ git init
$ touch a.txt
$ ln -s a.txt d
$ git add .
$ git commit -m + .
[master (root-commit) f6b4468] +
 2 files changed, 1 insertion(+)
 create mode 100644 a.txt
 create mode 120000 d
$ ls -la
total 12
drwxr-xr-x 3 ox ox 4096 Jan 19 14:10 .
drwxr-xr-x 4 ox ox 4096 Jan 19 14:04 ..
drwxr-xr-x 8 ox ox 4096 Jan 19 14:10 .git
-rw-r--r-- 1 ox ox    0 Jan 19 14:10 a.txt
lrwxrwxrwx 1 ox ox    5 Jan 19 14:10 d -> a.txt
$ rm d
$ mkdir d
$ touch d/b.txt
$ git add .
$ git commit . -m +
error: 'd' does not have a commit checked out
fatal: updating files failed


# I expect that git just replaces the link by the directory. But it makes problems.

# Workaround:

$ rm -rf d
$ git add .
$ git commit -m + .
[master 522e6db] +
 1 file changed, 1 deletion(-)
 delete mode 120000 d
$ mkdir d
$ touch d/b.txt
$ git add .
$ git commit -m + .
[master 8a125ee] +
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 d/b.txt

[System Info]
git version:
git version 2.43.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.25-1 (2023-04-22) x86_64
compiler info: gnuc: 13.2
libc info: glibc: 2.37
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Thanks in advance,
Frank Schwidom

Re: Bugreport

[brian m. carlson]

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

On 2024-01-19 at 13:25:51, Frank Schwidom wrote:
> 
> This bug exists in possibly all git versions.
> 
> $ git init
> $ touch a.txt
> $ ln -s a.txt d
> $ git add .
> $ git commit -m + .
> [master (root-commit) f6b4468] +
>  2 files changed, 1 insertion(+)
>  create mode 100644 a.txt
>  create mode 120000 d
> $ ls -la
> total 12
> drwxr-xr-x 3 ox ox 4096 Jan 19 14:10 .
> drwxr-xr-x 4 ox ox 4096 Jan 19 14:04 ..
> drwxr-xr-x 8 ox ox 4096 Jan 19 14:10 .git
> -rw-r--r-- 1 ox ox    0 Jan 19 14:10 a.txt
> lrwxrwxrwx 1 ox ox    5 Jan 19 14:10 d -> a.txt
> $ rm d
> $ mkdir d
> $ touch d/b.txt
> $ git add .
> $ git commit . -m +
> error: 'd' does not have a commit checked out
> fatal: updating files failed

I can confirm this behaviour[0], and it's definitely wrong that it
thinks `d` is a submodule.  It does, however, work if you do `git commit
-m +` (that is, without the .), which makes sense since the relevant
change is already staged in the index.

I'm not going to get to a patch or more thorough investigation, but
perhaps someone else will.

[0] git version 2.43.0.381.gb435a96ce8
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

partial commit of file-to-directory change, was Re: Bugreport

[Jeff King]

On Fri, Jan 19, 2024 at 11:14:47PM +0000, brian m. carlson wrote:

> > $ git commit . -m +
> > error: 'd' does not have a commit checked out
> > fatal: updating files failed
> 
> I can confirm this behaviour[0], and it's definitely wrong that it
> thinks `d` is a submodule.  It does, however, work if you do `git commit
> -m +` (that is, without the .), which makes sense since the relevant
> change is already staged in the index.
> 
> I'm not going to get to a patch or more thorough investigation, but
> perhaps someone else will.

I peeked at this a bit earlier; I didn't come up with a solution, but
here are a few more details.

As you noted, the problem is only with giving a pathspec to "git
commit". The bug is in the custom code git-commit uses to set up the
index for a partial commit. It generates a list of entries for the
partial commit via list_path(), and then tries to add them to the index.
But of course "d", being a directory, does not make any sense as an
index entry itself (unless as a submodule).

I'd have thought that we should just be using the same code that "git
add" does here (which obviously works). But all of this comes from
2888605c64 (builtin-commit: fix partial-commit support, 2007-11-18),
which explicitly says "you can't just run add_files_to_cache()", which
is what git-add does under the hood.

I don't know if we could revisit those assumptions and reuse some of the
existing code, or if the custom partial-commit code could be fixed.  I
guess the root of the issue is that in the call to list_paths(), we call
overlay_tree_on_index(). And that's how we end up thinking that "d" is a
useful path to talk about, even though it has already been removed from
the index (we have "d/b.txt" instead).

So I'm not sure if we need a solution here-ish:

diff --git a/builtin/commit.c b/builtin/commit.c
index 65196a2827..25e65e986d 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -302,7 +302,9 @@ static void add_remove_files(struct string_list *list)
 			continue;
 
 		if (!lstat(p->string, &st)) {
-			if (add_to_index(&the_index, p->string, &st, 0))
+			if (S_ISDIR(st.st_mode))
+				warning("woah, %s is a dir", p->string);
+			else if (add_to_index(&the_index, p->string, &st, 0))
 				die(_("updating files failed"));
 		} else
 			remove_file_from_index(&the_index, p->string);

but I'm not quite sure what we should be doing instead of that
warning(). Should we updating and including everything in "d/"? What
about if there were a "d/c.txt" that was not a tracked file at all?

It might also be that the bug is earlier in list_paths(), where we
should notice that "d" is gone and now we have entries under "d/".

I dunno. I probably won't dig much further on this myself, but it's
possible Junio (cc'd) might have an idea right away.

-Peff

Re: partial commit of file-to-directory change, was Re: Bugreport

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I dunno. I probably won't dig much further on this myself, but it's
> possible Junio (cc'd) might have an idea right away.

Sorry, but I do not have any idea "right away".  I even needed to
see the tree of 2888605c64 and check if we had submodules back then
(it turns out that we did).

Re: partial commit of file-to-directory change, was Re: Bugreport

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> It might also be that the bug is earlier in list_paths(), where we
> should notice that "d" is gone and now we have entries under "d/".

We had a related discussion on "commit -i/-o tests" review thread,
where we noticed that "git commit -i foobar", when "foobar" does not
match any path in the index, silently ignore that unmatching
pathspec (but "commit -o foobar" does error out, saying "did not
match any file(s) known to git").  The important design decision we
made long time ago when we introduced partial commit ("commit -o
pathspec") is that we do not _add_ paths (that match the pathspec)
that are not tracked.  We require explicit "git add" for them before
you run "git commit".

So, I suspect that list_paths() that gives "d" as a thing to add is
broken.  "commit -m + ." at that point is saying "we should get the
latest contents from the working tree for all the paths in the real
index, add[*] them to the temporary index freshly read from HEAD,
and the resulting temporary index should be written out as a tree"
to create a commit, and then "the same set of contents for the paths
then should be added to the real index, so that the differences
between the tree we wrote out of the temporary index to update the
HEAD and the real index would still be the changes already in the
index before this partial commit".

    Side note: here, "add" would include removing (if the working
    tree file for the path is gone) or killing 'd' while adding
    'd/b.txt'.

So I would understand if 'd/b.txt' is listed (because in the real
index there already is d/b.txt known), but if the directory 'd'
itself is listed, that does sound like a bug.

Re: partial commit of file-to-directory change, was Re: Bugreport

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Jan 19, 2024 at 11:14:47PM +0000, brian m. carlson wrote:
>
>> > $ git commit . -m +
>> > error: 'd' does not have a commit checked out
>> > fatal: updating files failed
>> 
>> I can confirm this behaviour[0], and it's definitely wrong that it
>> thinks `d` is a submodule.  It does, however, work if you do `git commit
>> -m +` (that is, without the .), which makes sense since the relevant
>> change is already staged in the index.
>> 
>> I'm not going to get to a patch or more thorough investigation, but
>> perhaps someone else will.
>
> I peeked at this a bit earlier; I didn't come up with a solution, but
> here are a few more details.

I didn't either X-<, and the thing is somewhat nasty, as there are two
states (HEAD and the index) involved.

 * For paths that do not match the pathspec, we want to take the
   version from the HEAD.  For paths that do match the pathspec, we
   want to take the version from the working tree.  And after making
   the partial commit with such changes, we want to make the same
   change to the index to prepare for the next commit.

 * With the way the code is currently structured, we find paths that
   appear either in the index or in the HEAD to match against the
   pathspec.  This is so that we can honor an earlier "git rm" since
   we read HEAD.

 * Then we check each of these paths that are either in the index or
   in HEAD that matched the pathspec.  If it is missing from the
   working tree, we would remove it from both the temporary ndex
   used for the partial commit, and the real index that we'll
   continue to use after the partial commit.  If it exists in the
   working tree, we would take the contents of it to update.

   For the purpose of this operation, a path D that was a blob in
   the index should be _removed_ when it is a directory in the
   working tree (i.e. made room to create D/F).  And we should not
   add D/F when running "git commit D" or "git commit D/F", because
   the partial commit does not "git add" (it only does "git add -u")

In the example in the discussion, we had D that was a blob and got
replaced with a directory.  If we did "git add -u D", we would just
have removed D from the index, so the partial commit should do the
same.  Which means we need to know the type of the thing we expect.
But list_paths() only returns a list of path names, and does not
give us the type of the thing we expect.  We use the same list
twice, once to update the temporary index (which we create by
reading HEAD) and update the paths listed there from the working
tree.  And the same list is used again to update the real index
(which is what the user had before starting the command) and update
the paths listed there from the working tree.  The tricky part is
that the type of (or even existence of) D may have changed between
the HEAD and the index, but we want to perform the same operation to
the real index with respect to the paths we touched to create the
partial commit.

Naively, add_remove_files() looks like an obvious place to see if
the path is in the working tree (which we already do) *and* compare
it with "the type of the thing we expect", but the thing is that
this function is called twice with different index (once with the
temporary index that started from HEAD, i.e. oblivious to what the
user did to the index since HEAD; then again with the real index
with the changes the user made since HEAD), so we cannot just say
"let's see what this path D is in the index".

I _think_ we would need to update list_paths() so that it records a
bit more than just pathnames that match the pathspec, namely, what
should be done to the path, by doing lstat() on the working tree
paths.

Bugreport

[do Carmo Lucas, Dr. Amilcar (T-PSC)]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Using git "difftool --dir-diff" on windows on a lfs repository

What did you expect to happen? (Expected behavior)
I expected it to call the configured tool with no errors

What happened instead? (Actual behavior)
I get the error
error: could not symlink 'D:/xxxx/KUS.a2l' to 'C:\xxxx/KUS.a2l': Function not implemented

To fix this I need to call difftool with "--no-symlinks" but the documentation mentions that "--no-symlinks" is the default on windows. Well, it clearly isn't.

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

Anything else you want to add:

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.52.0.windows.1
cpu: x86_64
built from commit: 2912d8e9b8253723974b7baf1c890273b1a1c5bd
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
libcurl: 8.17.0
OpenSSL: OpenSSL 3.5.4 30 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Windows 10.0 26100 
compiler info: gnuc: 15.2
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>


[Enabled Hooks]
commit-msg
pre-commit

Mit freundlichen Grüßen,

Dr.-Ing. Amilcar Lucas


IAV – your Tech Solution Provider
Your one stop shop for the Software Defined Vehicle and all Powertrains

IAV GmbH Ingenieurgesellschaft Auto und Verkehr; Sitz/Registered Office: Berlin; Registergericht/Registration Court: Amtsgericht Charlottenburg (Berlin); Registernummer/Company Registration Number: HRB 21 280 B; Geschäftsführer/Managing Directors: Joerg Astalosch, Dr. Frauke Esser, Jens Pfitzinger; Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Nikolai Ardey

Bugreport

[Marcel Svitalský]

What did you do before the bug happened? (Steps to reproduce your issue)
I called `git lg` command to display git graph log in my terminal. The 
command is defined in my
general gitconfig file as follows:

# double liner with hash, time, branches and tags on first line and the 
message on second
lg = "!f() { num=15; if [ \"$1\" != \"\" ] && ( echo \"$1\" | grep -q 
\"^[0-9]\\\\+\\$\" ) ; then num=\"$1\" ; shift ; fi ; [ $num -eq 0 ] && 
num=999999999 ; git \"$@\" log -n \"$num\" --graph --abbrev-commit 
--decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold 
cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold 
yellow)%d%C(reset)%n'' %C(white)%s%C(reset)' --all; }; f"

What did you expect to happen? (Expected behavior)
I expected to see git graph log with the project commits.

What happened instead? (Actual behavior)
On top of the project commits were added these four pseudo-commits made 
by some Git component(s).

* f7b611ce - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
|  Notes added by 'git notes append' - rewrite-analytics
* 1a7605bb - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
|  Notes added by 'git notes append' - rewrite-analytics
* c2a05d79 - Wed, 12 Aug 2026 09:25:03 +0200 (5 hours ago)
|  Notes added by 'git notes append' - rewrite-analytics
  \
   * 01c630e0 - Wed, 12 Aug 2026 09:13:00 +0200 (5 hours ago)
      chatter: initialize notes ref - chatter

They are not graphically connected with the actual commits, they just 
sit there over them. No other graphical
tool (Sublime Merge, IntelliJ Idea) displays them.
Originally, when I opened the project, only the first (chronologically) 
commit (by chatter) appeared,
and those by rewrite-analytics seem to be added with actual commits in 
branches, each for one branch.
Sometimes after more commits or merges they disappear and after removing 
(`git reset --hard`) those new
commits/merges they re-appear (I played with it a little).
They are not always on top, sometimes when a new commit in a branch is 
made it gets on top and these
pseudo-commits sit beside (to the right) of the graph log, still 
unconnected.

What's different between what you expected and what actually happened?
Those pseudo-commits.

Anything else you want to add: The terminal is tmux running on 
mate-terminal.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.55.0.559.g11c6700f10
cpu: x86_64
built from commit: 11c6700f10234578d10523faf35656ca491425c9
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: enabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.21.0
OpenSSL: OpenSSL 3.6.3 9 Jun 2026
zlib: 1.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 7.1.6-1-MANJARO #1 SMP PREEMPT_DYNAMIC Mon, 03 Aug 2026 
10:34:01 +0000 x86_64
compiler info: gnuc: 16.1
libc info: glibc: 2.44
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: Bugreport

[Kristoffer Haugsbakk]

I have only skimmed this.

On Wed, Aug 12, 2026, at 14:31, Marcel Svitalský wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
> I called `git lg` command to display git graph log in my terminal. The
> command is defined in my
> general gitconfig file as follows:
>
> # double liner with hash, time, branches and tags on first line and the
> message on second
> lg = "!f() { num=15; if [ \"$1\" != \"\" ] && ( echo \"$1\" | grep -q
> \"^[0-9]\\\\+\\$\" ) ; then num=\"$1\" ; shift ; fi ; [ $num -eq 0 ] &&
> num=999999999 ; git \"$@\" log -n \"$num\" --graph --abbrev-commit
> --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold
> cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold
> yellow)%d%C(reset)%n'' %C(white)%s%C(reset)' --all; }; f"

Note the `--all`.

> What did you expect to happen? (Expected behavior)
> I expected to see git graph log with the project commits.
>
> What happened instead? (Actual behavior)
> On top of the project commits were added these four pseudo-commits made
> by some Git component(s).
>
> * f7b611ce - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
> |  Notes added by 'git notes append' - rewrite-analytics
> * 1a7605bb - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
> |  Notes added by 'git notes append' - rewrite-analytics
> * c2a05d79 - Wed, 12 Aug 2026 09:25:03 +0200 (5 hours ago)
> |  Notes added by 'git notes append' - rewrite-analytics
>   \
>    * 01c630e0 - Wed, 12 Aug 2026 09:13:00 +0200 (5 hours ago)
>       chatter: initialize notes ref - chatter
>
> They are not graphically connected with the actual commits, they just
> sit there over them. No other graphical
> tool (Sublime Merge, IntelliJ Idea) displays them.

They are Git notes. They form their own connected graph. That’s why they
are not connected with the “actual commits” like from some branch.

The `--all` will include all refs, including Git notes like
`refs/notes/commits`.

This doesn’t look like a bug.

>[snip]

Re: Bugreport

[Marcel Svitalský]

I see, thank you. Is this a new feature? I've been using this command 
for years
and today is the first time I am seeing this. Also, is there another 
flag instead of
`--all` that would just include the actual commits only?

Thank you, best regards
Marcel Svitalský

On 12/08/2026 14:54, Kristoffer Haugsbakk wrote:
> I have only skimmed this.
>
> On Wed, Aug 12, 2026, at 14:31, Marcel Svitalský wrote:
>> What did you do before the bug happened? (Steps to reproduce your issue)
>> I called `git lg` command to display git graph log in my terminal. The
>> command is defined in my
>> general gitconfig file as follows:
>>
>> # double liner with hash, time, branches and tags on first line and the
>> message on second
>> lg = "!f() { num=15; if [ \"$1\" != \"\" ] && ( echo \"$1\" | grep -q
>> \"^[0-9]\\\\+\\$\" ) ; then num=\"$1\" ; shift ; fi ; [ $num -eq 0 ] &&
>> num=999999999 ; git \"$@\" log -n \"$num\" --graph --abbrev-commit
>> --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold
>> cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold
>> yellow)%d%C(reset)%n'' %C(white)%s%C(reset)' --all; }; f"
> Note the `--all`.
>
>> What did you expect to happen? (Expected behavior)
>> I expected to see git graph log with the project commits.
>>
>> What happened instead? (Actual behavior)
>> On top of the project commits were added these four pseudo-commits made
>> by some Git component(s).
>>
>> * f7b611ce - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
>> |  Notes added by 'git notes append' - rewrite-analytics
>> * 1a7605bb - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
>> |  Notes added by 'git notes append' - rewrite-analytics
>> * c2a05d79 - Wed, 12 Aug 2026 09:25:03 +0200 (5 hours ago)
>> |  Notes added by 'git notes append' - rewrite-analytics
>>    \
>>     * 01c630e0 - Wed, 12 Aug 2026 09:13:00 +0200 (5 hours ago)
>>        chatter: initialize notes ref - chatter
>>
>> They are not graphically connected with the actual commits, they just
>> sit there over them. No other graphical
>> tool (Sublime Merge, IntelliJ Idea) displays them.
> They are Git notes. They form their own connected graph. That’s why they
> are not connected with the “actual commits” like from some branch.
>
> The `--all` will include all refs, including Git notes like
> `refs/notes/commits`.
>
> This doesn’t look like a bug.
>
>> [snip]

Re: Bugreport

[D. Ben Knoble]

[please don't top-post]


> On 12/08/2026 14:54, Kristoffer Haugsbakk wrote:
> > I have only skimmed this.
> >
> > On Wed, Aug 12, 2026, at 14:31, Marcel Svitalský wrote:
> >> What did you do before the bug happened? (Steps to reproduce your issue)
> >> I called `git lg` command to display git graph log in my terminal. The
> >> command is defined in my
> >> general gitconfig file as follows:
> >>
> >> # double liner with hash, time, branches and tags on first line and the
> >> message on second
> >> lg = "!f() { num=15; if [ \"$1\" != \"\" ] && ( echo \"$1\" | grep -q
> >> \"^[0-9]\\\\+\\$\" ) ; then num=\"$1\" ; shift ; fi ; [ $num -eq 0 ] &&
> >> num=999999999 ; git \"$@\" log -n \"$num\" --graph --abbrev-commit
> >> --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold
> >> cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold
> >> yellow)%d%C(reset)%n'' %C(white)%s%C(reset)' --all; }; f"
> > Note the `--all`.
> >
> >> What did you expect to happen? (Expected behavior)
> >> I expected to see git graph log with the project commits.
> >>
> >> What happened instead? (Actual behavior)
> >> On top of the project commits were added these four pseudo-commits made
> >> by some Git component(s).
> >>
> >> * f7b611ce - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
> >> |  Notes added by 'git notes append' - rewrite-analytics
> >> * 1a7605bb - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
> >> |  Notes added by 'git notes append' - rewrite-analytics
> >> * c2a05d79 - Wed, 12 Aug 2026 09:25:03 +0200 (5 hours ago)
> >> |  Notes added by 'git notes append' - rewrite-analytics
> >>    \
> >>     * 01c630e0 - Wed, 12 Aug 2026 09:13:00 +0200 (5 hours ago)
> >>        chatter: initialize notes ref - chatter
> >>
> >> They are not graphically connected with the actual commits, they just
> >> sit there over them. No other graphical
> >> tool (Sublime Merge, IntelliJ Idea) displays them.
> > They are Git notes. They form their own connected graph. That’s why they
> > are not connected with the “actual commits” like from some branch.
> >
> > The `--all` will include all refs, including Git notes like
> > `refs/notes/commits`.
> >
> > This doesn’t look like a bug.
> >
> >> [snip]

On Wed, Aug 12, 2026 at 9:03 AM Marcel Svitalský
<marcel.svitalsky@gmail.com> wrote:
>
> I see, thank you. Is this a new feature? I've been using this command
> for years
> and today is the first time I am seeing this.

Notes are not new. Perhaps a tool you use started creating them?

> Also, is there another
> flag instead of
> `--all` that would just include the actual commits only?

You could limit the refs to be listed, like maybe "--branches --tags
--remotes", or "--exclude='refs/notes/*' --all" ? (I'm omitting
treatment of refs/stash, too, for now.)


-- 
D. Ben Knoble

Re: Bugreport

[Marcel Svitalský]

On 12/08/2026 15:14, D. Ben Knoble wrote:
> [please don't top-post]
>
>
>> On 12/08/2026 14:54, Kristoffer Haugsbakk wrote:
>>> I have only skimmed this.
>>>
>>> On Wed, Aug 12, 2026, at 14:31, Marcel Svitalský wrote:
>>>> What did you do before the bug happened? (Steps to reproduce your issue)
>>>> I called `git lg` command to display git graph log in my terminal. The
>>>> command is defined in my
>>>> general gitconfig file as follows:
>>>>
>>>> # double liner with hash, time, branches and tags on first line and the
>>>> message on second
>>>> lg = "!f() { num=15; if [ \"$1\" != \"\" ] && ( echo \"$1\" | grep -q
>>>> \"^[0-9]\\\\+\\$\" ) ; then num=\"$1\" ; shift ; fi ; [ $num -eq 0 ] &&
>>>> num=999999999 ; git \"$@\" log -n \"$num\" --graph --abbrev-commit
>>>> --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold
>>>> cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold
>>>> yellow)%d%C(reset)%n'' %C(white)%s%C(reset)' --all; }; f"
>>> Note the `--all`.
>>>
>>>> What did you expect to happen? (Expected behavior)
>>>> I expected to see git graph log with the project commits.
>>>>
>>>> What happened instead? (Actual behavior)
>>>> On top of the project commits were added these four pseudo-commits made
>>>> by some Git component(s).
>>>>
>>>> * f7b611ce - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
>>>> |  Notes added by 'git notes append' - rewrite-analytics
>>>> * 1a7605bb - Wed, 12 Aug 2026 09:26:03 +0200 (5 hours ago)
>>>> |  Notes added by 'git notes append' - rewrite-analytics
>>>> * c2a05d79 - Wed, 12 Aug 2026 09:25:03 +0200 (5 hours ago)
>>>> |  Notes added by 'git notes append' - rewrite-analytics
>>>>     \
>>>>      * 01c630e0 - Wed, 12 Aug 2026 09:13:00 +0200 (5 hours ago)
>>>>         chatter: initialize notes ref - chatter
>>>>
>>>> They are not graphically connected with the actual commits, they just
>>>> sit there over them. No other graphical
>>>> tool (Sublime Merge, IntelliJ Idea) displays them.
>>> They are Git notes. They form their own connected graph. That’s why they
>>> are not connected with the “actual commits” like from some branch.
>>>
>>> The `--all` will include all refs, including Git notes like
>>> `refs/notes/commits`.
>>>
>>> This doesn’t look like a bug.
>>>
>>>> [snip]
> On Wed, Aug 12, 2026 at 9:03 AM Marcel Svitalský
> <marcel.svitalsky@gmail.com> wrote:
>> I see, thank you. Is this a new feature? I've been using this command
>> for years
>> and today is the first time I am seeing this.
> Notes are not new. Perhaps a tool you use started creating them?

I suspect lazygit. Or Idea, I don't know and won't investigate any further.

>> Also, is there another
>> flag instead of
>> `--all` that would just include the actual commits only?
> You could limit the refs to be listed, like maybe "--branches --tags
> --remotes", or "--exclude='refs/notes/*' --all" ? (I'm omitting
> treatment of refs/stash, too, for now.)

Works fine, thank you very much (and yes, I now realize I could and 
should have
looked at the man page to begin with).

I suppose this can be closed now (I do not know the procedures here). 
Thanks again!

MS

Re: Bugreport

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

>> They are not graphically connected with the actual commits, they just
>> sit there over them. No other graphical
>> tool (Sublime Merge, IntelliJ Idea) displays them.
>
> They are Git notes. They form their own connected graph. That’s why they
> are not connected with the “actual commits” like from some branch.
>
> The `--all` will include all refs, including Git notes like
> `refs/notes/commits`.
>
> This doesn’t look like a bug.

Wow, I 100% agree with your conclusions, but it was unexpected even
to me that "git log --all" crawled anything outside branches,
remote-tracking branches, and tags.  I can sort-of understand why
the "rev-list" command at the plumbing layer may want to include
everything under refs/ hierarchy, but it is unexpected for the
end-user facing "git log".

Not that we want to or we can change it this late in the game,
though.  I wonder if "git log --all -p" also goes through the stash
refs as well as notes.

Re: Bugreport

[Junio C Hamano]

Marcel Svitalský <marcel.svitalsky@gmail.com> writes:

> I see, thank you. Is this a new feature? I've been using this command 
> for years
> and today is the first time I am seeing this. Also, is there another 
> flag instead of
> `--all` that would just include the actual commits only?

--branches
--tags
--remotes

Re: Bugreport

[Marcel Svitalský]

On 12/08/2026 19:04, Junio C Hamano wrote:
> Marcel Svitalský <marcel.svitalsky@gmail.com> writes:
>
>> I see, thank you. Is this a new feature? I've been using this command
>> for years
>> and today is the first time I am seeing this. Also, is there another
>> flag instead of
>> `--all` that would just include the actual commits only?
> --branches
> --tags
> --remotes
>

Thank you, I actually want stashes included in the log so I chose the
`--exclude='refs/notes/*' --all` solution suggested by D. Ben Knoble.

MS

Re: Bugreport

[Kristoffer Haugsbakk]

On Wed, Aug 12, 2026, at 19:03, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>[snip]
>>
>> They are Git notes. They form their own connected graph. That’s why they
>> are not connected with the “actual commits” like from some branch.
>>
>> The `--all` will include all refs, including Git notes like
>> `refs/notes/commits`.
>>
>> This doesn’t look like a bug.
>
> Wow, I 100% agree with your conclusions, but it was unexpected even
> to me that "git log --all" crawled anything outside branches,
> remote-tracking branches, and tags.  I can sort-of understand why
> the "rev-list" command at the plumbing layer may want to include
> everything under refs/ hierarchy, but it is unexpected for the
> end-user facing "git log".

Maybe `--all` was added before Git notes and that was the intent? Well,
they would known that it would include whatever custom refs that people
wanted. But then maybe they thought of it as:

• branches, remote-tracking branches, tags (from git(1))
• (git-stash(1) is an old command; I think it might have been an
  oversight to include it with `--all`? (see end of this message))
• whatever custom refs the repo uses; these you should know (?) and
  shouldn’t get surprised by

The custom refs would have been added by third-party programs, but
someone would have thought that it was worth going through the effort of
pushing out these refs to other people. Although, people could still be
surprised by mere bookkeeping data showing up with `--all`.[1]

***

Note for others: One doesn’t end up with Git notes added by git(1)[1]
*by others* that easily. ;) Branches and tags can be pushed out easily,
but you need an explicit refspec to push Git notes. And I don’t think
git-notes(1) mentions this. I would venture to bet that most people who
have learned to push out Git notes have learned it from StackOverflow or
some other not-Git project site.

And after someone has gone through the trouble of pushing them, other
people also need to fetch them with an explicit refspec.

† 1: By other programs is a different matter. Git notes are a great way
     to attach metadata to commits, so many third-party tools use
     that. And it might not matter to the end-user whether data about
     which commit messages have typos in them is stored in Git notes or
     in some Sqlite database, but `--all` will reveal that
     implementation detail if Notes are used.

>
> Not that we want to or we can change it this late in the game,
> though.  I wonder if "git log --all -p" also goes through the stash
> refs as well as notes.

It does show the commits from `refs/stash`.