On Thu, Jan 23, 2020 at 11:36:49AM -0500, Eric Sunshine wrote: > [cc:+peff] > > On Thu, Jan 23, 2020 at 11:32 AM SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > > On Thu, Jan 23, 2020 at 05:04:09PM +0100, ch wrote: > > > I recently updated my Git installation from 2.24.1.windows.2 to > > > 2.25.0.windows.1 and from the looks of it the included version of gitk does not > > > support being run from non-worktree folders of a repository anymore (like the > > > .git folder for example). > > I've stumbled upon the same issue when I tried to run 'gitk' in a bare > > repository a while ago, but it refused to run with the same error > > message. > > > > Are you sure it's a recent regression? I have no experience with > > 'gitk' in Git for Windows, but on Linux this has been broken for quite > > some time, namely since 784b7e2f25 (gitk: Fix "External diff" with > > separate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that > > commit on top of v2.25.0 makes 'gitk' work again in bare repositories. > > It's a new regression introduced by 2d92ab32fd (rev-parse: make > --show-toplevel without a worktree an error, 2019-11-19), as far as I > can tell. Oh, that's interesting. My local commit reverting 784b7e2f25 that I build my Git with is newer than 2d92ab32fd, so maybe that's why I haven't recalled seeing this issue earlier. I did try to bisect it, but had a real hard time with gitk being subtree merged, and ultimately gave up on that, and started to look for a commit adding '--show-toplevel' to 'gitk', which lead me to 784b7e2f25, I reverted it, my issue went away, which then lead me to the wrong conclusion. > I have many times used gitk on bare repositories as an > interactive replacement for git-log, so this is a unfortunate bit of > fallout from that change. That's not to say that 2d92ab32fd should be > reverted, though... perhaps gitk itself needs a bit of a fix. Well, I don't speak much tcl/tk, but as far as I understand the changes of 784b7e2f25, it added a 'git rev-parse --show-toplevel' invocation to 'gitk's main code path, but the result of that command is only used if the user clicks on the "External diff" menuitem in the "Patch" pane's context menu. So perhaps the scope of that 'git rev-parse --show-toplevel' could be limited, and executed only when the user actually clicks on that menuitem (I've never done that before, in fact I wasn't even aware that there is a context menu there).
