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
>>>
>>
>
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).