All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: ch <cr@onlinehome.de>,
	Martin von Zweigbergk <martinvonz@gmail.com>,
	Paul Mackerras <paulus@ozlabs.org>,
	Git List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [REGRESSION] gitk can't be run from non-worktree folders
Date: Thu, 23 Jan 2020 18:46:02 +0100	[thread overview]
Message-ID: <20200123174602.GE6837@szeder.dev> (raw)
In-Reply-To: <20200123170412.GD6837@szeder.dev>

On Thu, Jan 23, 2020 at 06:04:12PM +0100, SZEDER Gábor wrote:
> On Thu, Jan 23, 2020 at 11:36:49AM -0500, Eric Sunshine wrote:

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

Oh, this is interesting indeed :)

I have a couple of older Git versions lying around, so I can quickly
ballpark a revision range for a regression, without checking out and
building older versions.  This has always worked well so far, because
Git looks for its non-builtin commands in the hardcoded exec-path that
was specified at build time, while builtin commands are, well,
builtins.  Alas, 'gitk' is not a regular Git command, and it runs
whatever 'git' executable comes first in PATH, which in my case was a
recent build already containing 2d92ab32fd.

  $ ~/src/git/BUILDS/v1.8.0/bin/git --exec-path
  /home/szeder/src/git/BUILDS/v1.8.0/libexec/git-core
  $ cd .git
  $ ~/src/git/BUILDS/v1.8.0/bin/gitk
  Error in startup script: fatal: this operation must be run in a work
  tree
      while executing
  "exec git rev-parse --show-toplevel"
      invoked from within
  "set worktree [exec git rev-parse --show-toplevel]"
      (file "/home/szeder/src/git/BUILDS/v1.8.0/bin/gitk" line 11810)
  $ PATH=~/src/git/BUILDS/v1.8.0/bin:"$PATH" ~/src/git/BUILDS/v1.8.0/bin/gitk
  # Works even in the .git directory!
  $ PATH=~/src/git/BUILDS/v2.24.0/bin:"$PATH" ~/src/git/BUILDS/v2.24.0/bin/gitk
  # This works, too!

With this newly gained knowledge I added 'bin-wrappers' to $PATH when
running gitk built from 2d92ab32fd and its parent, and indeed that's
the commit that introduced this regression.


  reply	other threads:[~2020-01-23 17:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-23 16:04 [REGRESSION] gitk can't be run from non-worktree folders ch
2020-01-23 16:31 ` SZEDER Gábor
2020-01-23 16:36   ` Eric Sunshine
2020-01-23 17:04     ` SZEDER Gábor
2020-01-23 17:46       ` SZEDER Gábor [this message]
2020-01-23 19:02     ` Junio C Hamano
2020-01-23 19:20       ` [PATCH] gitk: to run in a bare repository (was: gitk can't be run from non-worktree folders) Junio C Hamano
2020-01-23 19:26         ` Eric Sunshine
2020-01-23 19:27         ` Jeff King
2020-03-30 15:20           ` ch
2020-10-11  5:08             ` Eric Sunshine
2020-10-13 14:25               ` [PATCH] gitk: to run in a bare repository ch
2020-10-13 15:31                 ` Pratyush Yadav
2020-04-02 13:40     ` [REGRESSION] gitk can't be run from non-worktree folders ch
2020-04-02 17:47     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200123174602.GE6837@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=cr@onlinehome.de \
    --cc=git@vger.kernel.org \
    --cc=martinvonz@gmail.com \
    --cc=paulus@ozlabs.org \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.