Git GUI fails to identify bare repository while TortoiseGit succeeds

Question

While I understand the difference between a bare and non-bare Git repositories, I am puzzled by how a bare repository is not identified as a valid repository by git-gui (despite successful push via Git Bash), while TortoiseGit has no issue identifying it as such (right-click inside Y:\as > TortoiseGit > Repo-browser):

Git Gui, on the other hand responds to the same exact Y:\as path with an error:

This is the same Git Gui that came with the official Git distribution:

Any idea why is? Is this a bug? as designed?

BTW, git-gui has no issue browsing the working directory matching same exact push/repo:

Answer 1

The screen capture you posted shows gitk, a GUI frontend to git log which will indeed work on any kind of repository -- bare or non bare. It is a tool independant from git-gui which can be run on its own, by simply invoking gitk from a terminal, or by double-clicking a shortcut if you have one.

From the view you show in your capture: you can see that you have a Help > About gitk entry in the menu.

Since you mention git gui, I imagine you are used to accessing this view by first running git gui, then selecting Repository > Visualize [my branch]'s History (or Repository > Visualize All Branch History)

---

git-gui itself, on the other hand, is geared towards editing your index (the files you stage or unstage before committing) by comparing it to your working tree (files on disk), and this requires a non-bare repository, which is why you get the error you mention when you try to target a bare repository.

---

Additionally, when invoking gitk from the command line, you can add almost any option you would pass to git log :

gitk                        # history of your active branch
gitk HEAD @{u}              # combined history of active branch + upstream
gitk foo bar origin/baz     # combined history of these 3 branches
gitk --all                  # combined history of all branches
gitk --follow -- that/file  # display only commits that modify that/file
gitk -G 'that word'         # filter history using one of the pickaxe options
# etc ...

you may also change these git log options on an active gitk window by going to View > Edit view ... [F4] and setting the options in the graphical window you see.

Answer 2

Additionally, when invoking gitk from the command line, you can add almost any option you would pass to git log.

Then make sure to use Git 2.41 (Q2 2023), if you are on Windows, as it is the case for this question:

See commit 99e70f3 (08 May 2023) by Junio C Hamano (gitster).
See commit 7dd272e (24 Jan 2023) by Nico Rieck (gix).
See commit bb5cb23 (24 Jan 2023) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 29b8a3f, 15 May 2023)}

gitk: escape file paths before piping to git log

^{Signed-off-by: Nico Rieck
Signed-off-by: Johannes Schindelin}

We just started piping the file paths via stdin instead of passing them via the command-line, to avoid running into command-line limitations.

However, since we now pipe the file paths, we need to take care of special characters.

This fixes git-for-windows/git issue 2293 ("gitk path filter fails with backslashes").