Re: git gui error with relocated repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/05/14 19:28, Chris Packham wrote:
> On 07/05/14 00:10, Pat Thoyts wrote:
>> Chris Packham <judge.packham@xxxxxxxxx> writes:
>>
>>> On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham <judge.packham@xxxxxxxxx> 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
>>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]