All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Packham <judge.packham@gmail.com>
To: patthoyts@users.sourceforge.net
Cc: GIT <git@vger.kernel.org>
Subject: Re: git gui error with relocated repository
Date: Wed, 07 May 2014 19:49:33 +1200	[thread overview]
Message-ID: <5369E58D.4030908@gmail.com> (raw)
In-Reply-To: <5369E0A3.4040701@gmail.com>

On 07/05/14 19:28, Chris Packham wrote:
> On 07/05/14 00:10, Pat Thoyts wrote:
>> Chris Packham <judge.packham@gmail.com> writes:
>>
>>> On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham <judge.packham@gmail.com> wrote:
>>>> Hi Pat,
>>>>
>>>> I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
>>>> which includes gitgui-0.19.0 and I'm getting a new error when I run
>>>> 'git gui' in a repository with a .git file (created by git submodule).
>>>>
>>>> I can send you a screencap of the error message off list if you want
>>>> but the text is
>>>>
>>>> "No working directory ../../../<repo>
>>>>
>>>> couldn't change working directory to ../../../<repo>: no such file or directory"
>>>
>>> My tcl is a little rusty but I think the problem might be this snippet.
>>>
>>> # v1.7.0 introduced --show-toplevel to return the canonical work-tree
>>> if {[package vsatisfies $_git_version 1.7.0]} {
>>>    if { [is_Cygwin] } {
>>>        catch {set _gitworktree [exec cygpath --windows [git rev-parse
>>> --show-toplevel]]}
>>>    } else {
>>>        set _gitworktree [git rev-parse --show-toplevel]
>>>    }
>>> } else {
>>>    # try to set work tree from environment, core.worktree or use
>>>    # cdup to obtain a relative path to the top of the worktree. If
>>>    # run from the top, the ./ prefix ensures normalize expands pwd.
>>>    if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {
>>>        set _gitworktree [get_config core.worktree]
>>>        if {$_gitworktree eq ""} {
>>>            set _gitworktree [file normalize ./[git rev-parse --show-cdup]]
>>>        }
>>>    }
>>> }
>>>
>>> The  vsatisfies call probably doesn't handle '2.0.0.rc0' and the
>>> fallback behaviour probably needs to normalise core.worktree
>>>
>>
>> The _git_version variable has already been trimmed to remove such
>> suffixes so the version comparison here will be ok. 
> 
> I don't think that's true 'git rev-parse --show-toplevel' does the right
> thing - if it's run.

We'll the trimming works but vstatisfies doesn't

  puts $_git_version
  puts [package vsatisfies $_git_version 1.7.0]

  2.0.0
  0

> 
>> It looks more likely
>> to be something to do with the .git being a file with a link being
>> mishandled. How did you setup this test repository with its link to a
>> parent?
>>
> 
> It's just a git clone of the parent and a git submodule init. A subtle
> thing to notice is that config.worktree is relative to $GIT_DIR. All the
> configuration was done by git without any intervention from me.
> 
>>>>
>>>> Here's some other info that might help
>>>>
>>>>   $ git --version
>>>>   git version 2.0.0.rc0
>>>>
>>>>   $ cat .git
>>>>   gitdir: ../.git/modules/<repo>
>>>>
>>>>   $ git rev-parse --git-dir
>>>>   /home/chris/src/<super>/.git/modules/<repo>
>>>>
>>>>   $ git config core.worktree
>>>>   ../../../<repo>
>>>>
>>>> Thanks,
>>>> Chris
>>>
>>
> 

  reply	other threads:[~2014-05-07  7:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  2:56 git gui error with relocated repository Chris Packham
2014-04-29  4:23 ` Chris Packham
2014-04-29 10:58   ` [GIT GUI PATCH] git-gui: unconditionally use rev-parse --show-toplevel Chris Packham
2014-05-06 12:10   ` git gui error with relocated repository Pat Thoyts
2014-05-07  7:28     ` Chris Packham
2014-05-07  7:49       ` Chris Packham [this message]
2014-05-13 21:24         ` [GIT GUI PATCH] git-gui: use vcompare when comparing the git version Jens Lehmann
2014-05-14  7:46           ` Chris Packham
2014-05-14  7:49           ` Jens Lehmann
2014-05-14 19:22             ` Junio C Hamano
2014-05-14 21:49               ` Junio C Hamano
2014-05-17 12:23                 ` Pat Thoyts
2014-05-17 19:49                   ` [GIT GUI PATCH v2] git-gui: tolerate major version changes " Jens Lehmann
2014-05-18  0:31                     ` Chris Packham
2014-05-18  3:01                     ` Eric Sunshine
2014-05-19 17:16                     ` 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=5369E58D.4030908@gmail.com \
    --to=judge.packham@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=patthoyts@users.sourceforge.net \
    /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.