{"thread":{"id":"52684","subject":"[REGRESSION] gitk can't be run from non-worktree folders","startedAt":"2020-01-23T16:04:12Z","lastAt":"2020-10-13T15:31:46Z","messageCount":15,"participants":["ch","SZEDER Gábor","Eric Sunshine","Junio C Hamano","Jeff King","Pratyush Yadav"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"390279","messageId":"4e2e5829-b9a7-b9b4-5605-ac28e8dbc45a@onlinehome.de","threadId":"52684","inReplyTo":null,"subject":"[REGRESSION] gitk can't be run from non-worktree folders","fromName":"ch","fromEmail":"cr@onlinehome.de","sentAt":"2020-01-23T16:04:09Z","receivedAt":"2020-01-23T16:04:12Z","isPatch":false,"sender":{"key":"cr@onlinehome.de","avatar":null},"body":"Hi all!\n\nI recently updated my Git installation from 2.24.1.windows.2 to\n2.25.0.windows.1 and from the looks of it the included version of gitk does not\nsupport being run from non-worktree folders of a repository anymore (like the\n.git folder for example).\n\nHere's a small reproduction recipe:\n\n $ git init repro\n $ cd repro\n $ git commit -m test --allow-empty\n $ cd .git\n $ gitk --all &\n\ngitk terminates with the message:\n\n fatal: this operation must be run in a work tree\n while executing\n \"exec git rev-parse --show-toplevel\"\n invoked from within\n \"set worktree [exec git rev-parse --show-toplevel]\"\n (file \"C:/Program Files/Git/mingw64/bin/gitk\" line 12634)\n\n-ch\n"},{"id":"390280","messageId":"20200123163151.GC6837@szeder.dev","threadId":"52684","inReplyTo":"4e2e5829-b9a7-b9b4-5605-ac28e8dbc45a@onlinehome.de","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-01-23T16:31:51Z","receivedAt":"2020-01-23T16:32:28Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 23, 2020 at 05:04:09PM +0100, ch wrote:\n> I recently updated my Git installation from 2.24.1.windows.2 to\n> 2.25.0.windows.1 and from the looks of it the included version of gitk does not\n> support being run from non-worktree folders of a repository anymore (like the\n> .git folder for example).\n> \n> Here's a small reproduction recipe:\n> \n> $ git init repro\n> $ cd repro\n> $ git commit -m test --allow-empty\n> $ cd .git\n> $ gitk --all &\n> \n> gitk terminates with the message:\n> \n> fatal: this operation must be run in a work tree\n> while executing\n> \"exec git rev-parse --show-toplevel\"\n> invoked from within\n> \"set worktree [exec git rev-parse --show-toplevel]\"\n> (file \"C:/Program Files/Git/mingw64/bin/gitk\" line 12634)\n\nI've stumbled upon the same issue when I tried to run 'gitk' in a bare\nrepository a while ago, but it refused to run with the same error\nmessage.\n\nAre you sure it's a recent regression? I have no experience with\n'gitk' in Git for Windows, but on Linux this has been broken for quite\nsome time, namely since 784b7e2f25 (gitk: Fix \"External diff\" with\nseparate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that\ncommit on top of v2.25.0 makes 'gitk' work again in bare repositories.\n\n"},{"id":"390281","messageId":"CAPig+cTixT9JYDPn-umKdQLtTm5byA1wwmvVY1ryuh+hv2=6MQ@mail.gmail.com","threadId":"52684","inReplyTo":"20200123163151.GC6837@szeder.dev","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-01-23T16:36:49Z","receivedAt":"2020-01-23T16:37:03Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"[cc:+peff]\n\nOn Thu, Jan 23, 2020 at 11:32 AM SZEDER Gábor wrote:\n> On Thu, Jan 23, 2020 at 05:04:09PM +0100, ch wrote:\n> > I recently updated my Git installation from 2.24.1.windows.2 to\n> > 2.25.0.windows.1 and from the looks of it the included version of gitk does not\n> > support being run from non-worktree folders of a repository anymore (like the\n> > .git folder for example).\n> I've stumbled upon the same issue when I tried to run 'gitk' in a bare\n> repository a while ago, but it refused to run with the same error\n> message.\n>\n> Are you sure it's a recent regression? I have no experience with\n> 'gitk' in Git for Windows, but on Linux this has been broken for quite\n> some time, namely since 784b7e2f25 (gitk: Fix \"External diff\" with\n> separate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that\n> commit on top of v2.25.0 makes 'gitk' work again in bare repositories.\n\nIt's a new regression introduced by 2d92ab32fd (rev-parse: make\n--show-toplevel without a worktree an error, 2019-11-19), as far as I\ncan tell. I have many times used gitk on bare repositories as an\ninteractive replacement for git-log, so this is a unfortunate bit of\nfallout from that change. That's not to say that 2d92ab32fd should be\nreverted, though... perhaps gitk itself needs a bit of a fix.\n"},{"id":"390283","messageId":"20200123170412.GD6837@szeder.dev","threadId":"52684","inReplyTo":"CAPig+cTixT9JYDPn-umKdQLtTm5byA1wwmvVY1ryuh+hv2=6MQ@mail.gmail.com","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-01-23T17:04:12Z","receivedAt":"2020-01-23T17:04:18Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 23, 2020 at 11:36:49AM -0500, Eric Sunshine wrote:\n> [cc:+peff]\n> \n> On Thu, Jan 23, 2020 at 11:32 AM SZEDER Gábor wrote:\n> > On Thu, Jan 23, 2020 at 05:04:09PM +0100, ch wrote:\n> > > I recently updated my Git installation from 2.24.1.windows.2 to\n> > > 2.25.0.windows.1 and from the looks of it the included version of gitk does not\n> > > support being run from non-worktree folders of a repository anymore (like the\n> > > .git folder for example).\n> > I've stumbled upon the same issue when I tried to run 'gitk' in a bare\n> > repository a while ago, but it refused to run with the same error\n> > message.\n> >\n> > Are you sure it's a recent regression? I have no experience with\n> > 'gitk' in Git for Windows, but on Linux this has been broken for quite\n> > some time, namely since 784b7e2f25 (gitk: Fix \"External diff\" with\n> > separate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that\n> > commit on top of v2.25.0 makes 'gitk' work again in bare repositories.\n> \n> It's a new regression introduced by 2d92ab32fd (rev-parse: make\n> --show-toplevel without a worktree an error, 2019-11-19), as far as I\n> can tell.\n\nOh, that's interesting.\n\nMy local commit reverting 784b7e2f25 that I build my Git with is newer\nthan 2d92ab32fd, so maybe that's why I haven't recalled seeing this\nissue earlier. I did try to bisect it, but had a real hard time with\ngitk being subtree merged, and ultimately gave up on that, and started\nto look for a commit adding '--show-toplevel' to 'gitk', which lead me\nto 784b7e2f25, I reverted it, my issue went away, which then lead me\nto the wrong conclusion.\n\n> I have many times used gitk on bare repositories as an\n> interactive replacement for git-log, so this is a unfortunate bit of\n> fallout from that change. That's not to say that 2d92ab32fd should be\n> reverted, though... perhaps gitk itself needs a bit of a fix.\n\nWell, I don't speak much tcl/tk, but as far as I understand the\nchanges of 784b7e2f25, it added a 'git rev-parse --show-toplevel'\ninvocation to 'gitk's main code path, but the result of that command\nis only used if the user clicks on the \"External diff\" menuitem in the\n\"Patch\" pane's context menu. So perhaps the scope of that 'git\nrev-parse --show-toplevel' could be limited, and executed only when\nthe user actually clicks on that menuitem (I've never done that\nbefore, in fact I wasn't even aware that there is a context menu\nthere).\n\n"},{"id":"390284","messageId":"20200123174602.GE6837@szeder.dev","threadId":"52684","inReplyTo":"20200123170412.GD6837@szeder.dev","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2020-01-23T17:46:02Z","receivedAt":"2020-01-23T17:46:14Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 23, 2020 at 06:04:12PM +0100, SZEDER Gábor wrote:\n> On Thu, Jan 23, 2020 at 11:36:49AM -0500, Eric Sunshine wrote:\n\n> > > Are you sure it's a recent regression? I have no experience with\n> > > 'gitk' in Git for Windows, but on Linux this has been broken for quite\n> > > some time, namely since 784b7e2f25 (gitk: Fix \"External diff\" with\n> > > separate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that\n> > > commit on top of v2.25.0 makes 'gitk' work again in bare repositories.\n> > \n> > It's a new regression introduced by 2d92ab32fd (rev-parse: make\n> > --show-toplevel without a worktree an error, 2019-11-19), as far as I\n> > can tell.\n> \n> Oh, that's interesting.\n> \n> My local commit reverting 784b7e2f25 that I build my Git with is newer\n> than 2d92ab32fd, so maybe that's why I haven't recalled seeing this\n> issue earlier. I did try to bisect it, but had a real hard time with\n> gitk being subtree merged, and ultimately gave up on that, and started\n> to look for a commit adding '--show-toplevel' to 'gitk', which lead me\n> to 784b7e2f25, I reverted it, my issue went away, which then lead me\n> to the wrong conclusion.\n\nOh, this is interesting indeed :)\n\nI have a couple of older Git versions lying around, so I can quickly\nballpark a revision range for a regression, without checking out and\nbuilding older versions. This has always worked well so far, because\nGit looks for its non-builtin commands in the hardcoded exec-path that\nwas specified at build time, while builtin commands are, well,\nbuiltins. Alas, 'gitk' is not a regular Git command, and it runs\nwhatever 'git' executable comes first in PATH, which in my case was a\nrecent build already containing 2d92ab32fd.\n\n $ ~/src/git/BUILDS/v1.8.0/bin/git --exec-path\n /home/szeder/src/git/BUILDS/v1.8.0/libexec/git-core\n $ cd .git\n $ ~/src/git/BUILDS/v1.8.0/bin/gitk\n Error in startup script: fatal: this operation must be run in a work\n tree\n while executing\n \"exec git rev-parse --show-toplevel\"\n invoked from within\n \"set worktree [exec git rev-parse --show-toplevel]\"\n (file \"/home/szeder/src/git/BUILDS/v1.8.0/bin/gitk\" line 11810)\n $ PATH=~/src/git/BUILDS/v1.8.0/bin:\"$PATH\" ~/src/git/BUILDS/v1.8.0/bin/gitk\n # Works even in the .git directory!\n $ PATH=~/src/git/BUILDS/v2.24.0/bin:\"$PATH\" ~/src/git/BUILDS/v2.24.0/bin/gitk\n # This works, too!\n\nWith this newly gained knowledge I added 'bin-wrappers' to $PATH when\nrunning gitk built from 2d92ab32fd and its parent, and indeed that's\nthe commit that introduced this regression.\n\n"},{"id":"390291","messageId":"xmqqpnfa3sj1.fsf@gitster-ct.c.googlers.com","threadId":"52684","inReplyTo":"CAPig+cTixT9JYDPn-umKdQLtTm5byA1wwmvVY1ryuh+hv2=6MQ@mail.gmail.com","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-23T19:02:42Z","receivedAt":"2020-01-23T19:02:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> It's a new regression introduced by 2d92ab32fd (rev-parse: make\n> --show-toplevel without a worktree an error, 2019-11-19), as far as I\n> can tell. I have many times used gitk on bare repositories as an\n> interactive replacement for git-log, so this is a unfortunate bit of\n> fallout from that change. That's not to say that 2d92ab32fd should be\n> reverted, though... perhaps gitk itself needs a bit of a fix.\n\nCurious.\n\nThere is a \"proc gitworktree\" that does use --show-toplevel but it\nis fairly conservative and assumes these calls can fail.\n\n ...\n if {[catch {set _gitworktree [exec git rev-parse --show-toplevel]}]} {\n if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {\n\t catch {set _gitworktree [exec git config --get core.worktree]}\n\t if {$_gitworktree eq \"\"} {\n\t\tset _gitworktree [file normalize ./[exec git rev-parse --show-cdup]]\n\t }\n\nHowever, there is this call\n\n set worktree [exec git rev-parse --show-toplevel]\n\nat the top-level of the code. I wonder if the obvious and minimum\nfix would be sufficient, i.e.\n\n -set worktree [exec git rev-parse --show-toplevel]\n +set worktree [gitworktree]\n\naround l.12546\n"},{"id":"390292","messageId":"xmqqk15i3rp7.fsf_-_@gitster-ct.c.googlers.com","threadId":"52684","inReplyTo":"xmqqpnfa3sj1.fsf@gitster-ct.c.googlers.com","subject":"[PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-23T19:20:36Z","receivedAt":"2020-01-23T19:20:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"[This message is designed to be readable by \"git am -c\".]\n\nJunio C Hamano writes:\n\n> Eric Sunshine writes:\n>\n>> It's a new regression introduced by 2d92ab32fd (rev-parse: make\n>> --show-toplevel without a worktree an error, 2019-11-19), as far as I\n>> can tell. I have many times used gitk on bare repositories as an\n>> interactive replacement for git-log, so this is a unfortunate bit of\n>> fallout from that change. That's not to say that 2d92ab32fd should be\n>> reverted, though... perhaps gitk itself needs a bit of a fix.\n>\n> Curious.\n>\n> There is a \"proc gitworktree\" that does use --show-toplevel but it\n> is fairly conservative and assumes these calls can fail.\n>\n> ...\n> if {[catch {set _gitworktree [exec git rev-parse --show-toplevel]}]} {\n> if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {\n> \t catch {set _gitworktree [exec git config --get core.worktree]}\n> \t if {$_gitworktree eq \"\"} {\n> \t\tset _gitworktree [file normalize ./[exec git rev-parse --show-cdup]]\n> \t }\n>\n> However, there is this call\n>\n> set worktree [exec git rev-parse --show-toplevel]\n>\n> at the top-level of the code. I wonder if the obvious and minimum\n> fix would be sufficient, i.e.\n>\n> -set worktree [exec git rev-parse --show-toplevel]\n> +set worktree [gitworktree]\n>\n> around l.12546\n\nI've read 784b7e2f (\"gitk: Fix \"External diff\" with separate work\ntree\", 2011-04-04) again and am reasonably convinced that the above\nsingle liner would be \"sufficient\". The external_diff_get_one_file\nproc is written, with or without the \"fix external diff\" patch, to\nwork ONLY in a non-bare repository (it used to find and use the\nparent directory of \".git\" as the top-level of the working tree\nbefore 784b7e2f, which changed it to use $worktree global obtained\nby calling \"rev-parse --show-toplevel\") and does not work in a bare\nrepository anyway, if I am reading the code correctly.\n\n\n-- >8 --\nSubject: [PATCH] gitk: be prepared to be run in a bare repository\n\n784b7e2f (\"gitk: Fix \"External diff\" with separate work tree\",\n2011-04-04) added an unconditional call to \"git rev-parse\n--show-toplevel\" to set up a global variable quite early in the\ncourse of the program, so that the location of the working tree can\nlater be known if/when the user chooses to run the external diff via\nthe external_diff_get_one_file proc. Before that change, the\nexternal diff code used to assume that the parent directory of \".git\"\ndirectory is the top-level of the working tree.\n\nRecent versions of git however notices that \"rev-parse --show-toplevel\"\nexecuted in a bare repository is an error, which makes gitk stop,\neven before the user could attempt to run external diff.\n\nUse the gitworktree helper introduced in 65bb0bda (\"gitk: Fix the\ndisplay of files when filtered by path\", 2011-12-13), which is\nprepared to see failures from \"rev-parse --show-toplevel\" and other\nmeans it tries to find the top-level of the working tree instead to\nwork around this issue. The resulting value in $worktree global,\nwhen run in a bare repository, is bogus, but the code is not\nprepared to run external diff correctly without a working tree\nanyway ;-)\n\nHelped-by: Eric Sunshine \nSigned-off-by: Junio C Hamano \n---\n gitk | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/gitk b/gitk\nindex abe4805ade..1483bf5ed5 100755\n--- a/gitk\n+++ b/gitk\n@@ -12599,7 +12599,7 @@ set cdup {}\n if {[expr {[exec git rev-parse --is-inside-work-tree] == \"true\"}]} {\n set cdup [exec git rev-parse --show-cdup]\n }\n-set worktree [exec git rev-parse --show-toplevel]\n+set worktree [gitworktree]\n setcoords\n makewindow\n catch {\n\n"},{"id":"390293","messageId":"20200123192638.GA3177@flurp.local","threadId":"52684","inReplyTo":"xmqqk15i3rp7.fsf_-_@gitster-ct.c.googlers.com","subject":"Re: [PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-01-23T19:26:38Z","receivedAt":"2020-01-23T19:26:47Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n> Use the gitworktree helper introduced in 65bb0bda (\"gitk: Fix the\n> display of files when filtered by path\", 2011-12-13), which is\n> prepared to see failures from \"rev-parse --show-toplevel\" and other\n> means it tries to find the top-level of the working tree instead to\n> work around this issue. The resulting value in $worktree global,\n> when run in a bare repository, is bogus, but the code is not\n> prepared to run external diff correctly without a working tree\n> anyway ;-)\n> \n> Helped-by: Eric Sunshine \n> Signed-off-by: Junio C Hamano \n> ---\n> diff --git a/gitk b/gitk\n> @@ -12599,7 +12599,7 @@ set cdup {}\n> if {[expr {[exec git rev-parse --is-inside-work-tree] == \"true\"}]} {\n> set cdup [exec git rev-parse --show-cdup]\n> }\n> -set worktree [exec git rev-parse --show-toplevel]\n> +set worktree [gitworktree]\n\nThis helps but doesn't quite make it functional due to a bug in gitworktree() which results in:\n\n Error in startup script: can't read \"_gitworktree\": no such variable\n while executing\n \"if {$_gitworktree eq \"\"} {\n\nSo, to make this work, it also needs:\n\n--- >8 ---\ndiff --git a/gitk-git/gitk b/gitk-git/gitk\nindex abe4805ade..8cbca113e3 100755\n--- a/gitk-git/gitk\n+++ b/gitk-git/gitk\n@@ -34,8 +34,7 @@ proc gitworktree {} {\n # cdup to obtain a relative path to the top of the worktree. If\n # run from the top, the ./ prefix ensures normalize expands pwd.\n if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {\n-\t catch {set _gitworktree [exec git config --get core.worktree]}\n-\t if {$_gitworktree eq \"\"} {\n+\t if {[catch {set _gitworktree [exec git config --get core.worktree]}]} {\n \t\tset _gitworktree [file normalize ./[exec git rev-parse --show-cdup]]\n \t }\n }\n--- >8 ---\n"},{"id":"390294","messageId":"20200123192707.GA110440@coredump.intra.peff.net","threadId":"52684","inReplyTo":"xmqqk15i3rp7.fsf_-_@gitster-ct.c.googlers.com","subject":"Re: [PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-23T19:27:07Z","receivedAt":"2020-01-23T19:27:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n\n> -- >8 --\n> Subject: [PATCH] gitk: be prepared to be run in a bare repository\n\nThanks all for cleaning up the mess I caused. I do prefer adjusting gitk\nlike this rather than reverting the change in Git. Despite the\nregression, I think the case of \"--show-toplevel without a working tree\"\nis sufficiently undefined that it's probably good for callers to\nactually decide what the right behavior is.\n\n> Recent versions of git however notices that \"rev-parse --show-toplevel\"\n> executed in a bare repository is an error, which makes gitk stop,\n> even before the user could attempt to run external diff.\n\nIt might be worth mentioning 2d92ab32 by name in this paragraph of the\ncommit message.\n\n-Peff\n"},{"id":"394365","messageId":"8be28321-3108-4846-ac6a-d5c7977774dc@onlinehome.de","threadId":"52684","inReplyTo":"20200123192707.GA110440@coredump.intra.peff.net","subject":"Re: [PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders)","fromName":"ch","fromEmail":"cr@onlinehome.de","sentAt":"2020-03-30T15:20:47Z","receivedAt":"2020-03-30T15:21:04Z","isPatch":true,"sender":{"key":"cr@onlinehome.de","avatar":null},"body":"Sorry for bumping this thread but what's the integration status of the patch?\nThe issue still seems to be present in v2.26.0.windows.1.\n\nOn Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n\n > -- >8 --\n > Subject: [PATCH] gitk: be prepared to be run in a bare repository\n"},{"id":"394584","messageId":"3c1a3e23-cf52-48cc-e9b6-f80642ca67ac@onlinehome.de","threadId":"52684","inReplyTo":"CAPig+cTixT9JYDPn-umKdQLtTm5byA1wwmvVY1ryuh+hv2=6MQ@mail.gmail.com","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"ch","fromEmail":"cr@onlinehome.de","sentAt":"2020-04-02T13:40:42Z","receivedAt":"2020-04-02T13:40:52Z","isPatch":false,"sender":{"key":"cr@onlinehome.de","avatar":null},"body":"I haven't actually bisected it but the change possibly also broke\ngit-gui-browser on bare repositories.\n\nThe follow patch seems to fix the issue. As I stated in my original bug report\nI'm using Git for Windows so maybe it does not apply cleanly on upstream Git.\n\n-- >8 --\n\n--- git-gui.tcl\t2020-03-23 12:22:36.000000000 +0100\n+++ git-gui-fixed.tcl\t2020-04-01 17:35:26.092223600 +0200\n@@ -1286,7 +1286,7 @@\n \tif { [is_Cygwin] } {\n \t\tcatch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}\n \t} else {\n-\t\tset _gitworktree [git rev-parse --show-toplevel]\n+\t\tcatch {set _gitworktree [git rev-parse --show-toplevel]}\n \t}\n } else {\n \t# try to set work tree from environment, core.worktree or use\n\n-- >8 --\n\nOn 23.01.2020 17:36, Eric Sunshine wrote:\n\n> It's a new regression introduced by 2d92ab32fd (rev-parse: make\n> --show-toplevel without a worktree an error, 2019-11-19), as far as I\n> can tell. I have many times used gitk on bare repositories as an\n> interactive replacement for git-log, so this is a unfortunate bit of\n> fallout from that change. That's not to say that 2d92ab32fd should be\n> reverted, though... perhaps gitk itself needs a bit of a fix.\n> \n"},{"id":"394612","messageId":"xmqqwo6x3hm3.fsf@gitster.c.googlers.com","threadId":"52684","inReplyTo":"CAPig+cTixT9JYDPn-umKdQLtTm5byA1wwmvVY1ryuh+hv2=6MQ@mail.gmail.com","subject":"Re: [REGRESSION] gitk can't be run from non-worktree folders","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-02T17:47:00Z","receivedAt":"2020-04-02T17:47:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> [cc:+peff]\n>\n> On Thu, Jan 23, 2020 at 11:32 AM SZEDER Gábor wrote:\n>> On Thu, Jan 23, 2020 at 05:04:09PM +0100, ch wrote:\n>> > I recently updated my Git installation from 2.24.1.windows.2 to\n>> > 2.25.0.windows.1 and from the looks of it the included version of gitk does not\n>> > support being run from non-worktree folders of a repository anymore (like the\n>> > .git folder for example).\n>> I've stumbled upon the same issue when I tried to run 'gitk' in a bare\n>> repository a while ago, but it refused to run with the same error\n>> message.\n>>\n>> Are you sure it's a recent regression? I have no experience with\n>> 'gitk' in Git for Windows, but on Linux this has been broken for quite\n>> some time, namely since 784b7e2f25 (gitk: Fix \"External diff\" with\n>> separate work tree, 2011-04-04) in the v1.7 era. FWIW, reverting that\n>> commit on top of v2.25.0 makes 'gitk' work again in bare repositories.\n>\n> It's a new regression introduced by 2d92ab32fd (rev-parse: make\n> --show-toplevel without a worktree an error, 2019-11-19), as far as I\n> can tell. I have many times used gitk on bare repositories as an\n> interactive replacement for git-log, so this is a unfortunate bit of\n> fallout from that change. That's not to say that 2d92ab32fd should be\n> reverted, though... perhaps gitk itself needs a bit of a fix.\n\nI thought we already saw a patch to do so?\n\n https://lore.kernel.org/git/20200123192638.GA3177@flurp.local/\n\nperhaps?\n\nPaul?\n"},{"id":"407287","messageId":"CAPig+cT1drHWic4bm=NPMd4RnGuLe-WwUJ-82nHkze_ZOoYerg@mail.gmail.com","threadId":"52684","inReplyTo":"8be28321-3108-4846-ac6a-d5c7977774dc@onlinehome.de","subject":"Re: [PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders)","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2020-10-11T05:08:45Z","receivedAt":"2020-10-11T05:09:00Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Mar 30, 2020 at 11:21 AM ch wrote:\n> On Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n> > Subject: [PATCH] gitk: be prepared to be run in a bare repository\n>\n> Sorry for bumping this thread but what's the integration status of the patch?\n> The issue still seems to be present in v2.26.0.windows.1.\n\nJunio just recently pulled commits into git.git from Paul's gitk\nrepository which contain this fix, and it looks like it will make it\ninto the Git 2.29.0 release.\n"},{"id":"407447","messageId":"96216301-e831-3fd0-8bd8-8d0d752c580c@onlinehome.de","threadId":"52684","inReplyTo":"CAPig+cT1drHWic4bm=NPMd4RnGuLe-WwUJ-82nHkze_ZOoYerg@mail.gmail.com","subject":"Re: [PATCH] gitk: to run in a bare repository","fromName":"ch","fromEmail":"cr@onlinehome.de","sentAt":"2020-10-13T14:25:10Z","receivedAt":"2020-10-13T14:26:04Z","isPatch":true,"sender":{"key":"cr@onlinehome.de","avatar":null},"body":"Sounds good. Thanks for the heads-up!\n\nWill the release also include a fix for git-gui (which exhibits\nsimilar behavior as gitk; see [0])?\n\n-ch\n\n[0] https://lore.kernel.org/git/3c1a3e23-cf52-48cc-e9b6-f80642ca67ac@onlinehome.de/\n\nOn 11.10.2020 07:08, Eric Sunshine wrote:\n> On Mon, Mar 30, 2020 at 11:21 AM ch wrote:\n>> On Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n>> > Subject: [PATCH] gitk: be prepared to be run in a bare repository\n>>\n>> Sorry for bumping this thread but what's the integration status of the patch?\n>> The issue still seems to be present in v2.26.0.windows.1.\n> \n> Junio just recently pulled commits into git.git from Paul's gitk\n> repository which contain this fix, and it looks like it will make it\n> into the Git 2.29.0 release.\n> \n"},{"id":"407453","messageId":"87blh66t2d.fsf@yadavpratyush.com","threadId":"52684","inReplyTo":"96216301-e831-3fd0-8bd8-8d0d752c580c@onlinehome.de","subject":"Re: [PATCH] gitk: to run in a bare repository","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2020-10-13T15:31:38Z","receivedAt":"2020-10-13T15:31:46Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On Tue, Oct 13 2020, ch wrote:\n\nHi,\n\nPlease avoid top posting.\n\n> Sounds good. Thanks for the heads-up!\n>\n> Will the release also include a fix for git-gui (which exhibits\n> similar behavior as gitk; see [0])?\n>\n> -ch\n>\n> [0] https://lore.kernel.org/git/3c1a3e23-cf52-48cc-e9b6-f80642ca67ac@onlinehome.de/\n\nI'm seeing this patch for the first time. It was never formally\nsubmitted to me. So as of now I have not queued it for the next release.\nI'll take a look at the problem and see if the patch is the correct fix\nand integrate it before the 2.29 release. But I don't have a lot of free\ntime so no promises.\n\n>\n> On 11.10.2020 07:08, Eric Sunshine wrote:\n>> On Mon, Mar 30, 2020 at 11:21 AM ch wrote:\n>>> On Thu, Jan 23, 2020 at 11:20:36AM -0800, Junio C Hamano wrote:\n>>> > Subject: [PATCH] gitk: be prepared to be run in a bare repository\n>>>\n>>> Sorry for bumping this thread but what's the integration status of the patch?\n>>> The issue still seems to be present in v2.26.0.windows.1.\n>> Junio just recently pulled commits into git.git from Paul's gitk\n>> repository which contain this fix, and it looks like it will make it\n>> into the Git 2.29.0 release.\n>> \n>\n\n-- \nRegards,\nPratyush Yadav\n"}]}