threads / discuss / 36532

git gui error with relocated repository

Subject: git gui error with relocated repository

## tl;dr

16 messages between Apr 29, 2014 and May 19, 2014.

replies: 15people: 5as markdown or json

Chris Packham· Apr 29, 2014, 02:56 UTC · lore
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"
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

Chris Packham· Apr 29, 2014, 04:23 UTC · re: Chris Packham · lore

Re: git gui error with relocated repository

On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham <judge.packham@gmail.com> wrote:
Show 12 quoted lines
> 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

Show 17 quoted lines
>
> 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
Chris Packham· Apr 29, 2014, 10:58 UTC · re: Chris Packham · lore

[GIT GUI PATCH] git-gui: unconditionally use rev-parse --show-toplevel

Previously 'git rev-parse --show-toplevel' was used to determine the canonical work-tree only when the installed git version was detected to be 1.7.0 or better. The fall-back logic used the core.worktree config variable which in the case of a submodule is a relative path from the submodule's $GIT_DIR. Unfortunately vsatisfies doesn't handle versions like v2.0.0.rc0 so the fall-back logic is triggered.

Given the fact that git 1.7.0 was released over 4 years ago rather than fixing the fall-back logic it seems reasonable to drop the version check.

Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
So I'm not sure if vsatisfies is failing because the version has .rc0 or
because it thinks v2.0.0 < 1.7.0. Regardless I think it's reasonably safe to
assume that people who are using the newer versions of git-gui are running new
enough versions of git.

There is also a similar section in rescan_stage2 that is checking for the version being 1.6.3 or newer. Again I think it's probably safe to assume that no-one is running a version of git that old (or at least no-one that wants to run this version of git-gui). I'm not quite sure how to excercise that bit of code so I haven't attempted to fix that.

 git-gui.sh | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index cf2209b..9ded5b9 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1282,23 +1282,11 @@ if {![file isdirectory $_gitdir]} {
 load_config 0
 apply_config
 
-# 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]
-	}
+# Determine the canonical work-tree
+if { [is_Cygwin] } {
+	catch {set _gitworktree [exec cygpath --windows [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]]
-		}
-	}
+	set _gitworktree [git rev-parse --show-toplevel]
 }
 
 if {$_prefix ne {}} {
-- 
1.8.2.rc1.4.g27db5a0
Pat Thoyts· May 6, 2014, 12:10 UTC · re: Chris Packham · lore

Re: git gui error with relocated repository

Chris Packham <judge.packham@gmail.com> writes:
Show 39 quoted lines
>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. 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?

Show 18 quoted lines
>>
>> 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
>
-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
Chris Packham· May 7, 2014, 07:28 UTC · re: Pat Thoyts · lore

Re: git gui error with relocated repository

On 07/05/14 00:10, Pat Thoyts wrote:
Show 44 quoted lines
> 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.

Show 5 quoted lines
> 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.

Show 19 quoted lines
>>>
>>> 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
>>
> 
Chris Packham· May 7, 2014, 07:49 UTC · re: Chris Packham · lore

Re: git gui error with relocated repository

On 07/05/14 19:28, Chris Packham wrote:
Show 48 quoted lines
> 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
Show 31 quoted lines
> 
>> 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
>>>
>>
> 
Jens Lehmann· May 13, 2014, 21:24 UTC · re: Chris Packham · lore

[GIT GUI PATCH] git-gui: use vcompare when comparing the git version

Since git 2.0.0 starting git gui in a submodule using a gitfile fails with the following error:

   No working directory ../../../<path>
   couldn't change working directory
   to "../../../<path>": no such file or
   directory

This is because "git rev-parse --show-toplevel" is only run when git gui sees a git version of at least 1.7.0 (which is the version in which the --show-toplevel option was introduced). But it uses vsatisfies to check that, which is documented to return false when the major version changes, which is not what we want here.

Change vsatisfies to vcompare when testing for a git version to avoid the problem when the major version changes (but still use vsatisfies in those places where the Tk version is checked). This is done for both the place that caused the reported bug and another spot where the git version is tested for another feature.

Reported-by: Chris Packham <judge.packham@gmail.com>
Reported-by: Yann Dirson <ydirson@free.fr>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 07.05.2014 09:49, schrieb Chris Packham:
Show 57 quoted lines
> 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

Yup, looks like vsatisfies is doing just what it is supposed to (according to http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/package.n.html):

   package vsatisfies version1 version2
       Returns 1 if scripts written for version2 will work unchanged
       with version1 (i.e. version1 is equal to or greater than version2
       and they both have the same major version number), 0 otherwise.

The bump in the major number from 1 to 2 makes vsatisfies assume that the version is not compatible anymore, I believe we should have used vcompare here and in another place.

 git-gui.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index cf2209b..ed2418b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1283,7 +1283,7 @@ load_config 0
 apply_config

 # v1.7.0 introduced --show-toplevel to return the canonical work-tree
-if {[package vsatisfies $_git_version 1.7.0]} {
+if {[package vcompare $_git_version 1.7.0]} {
 	if { [is_Cygwin] } {
 		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
 	} else {
@@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
 		close $fd
 	}

-	if {[package vsatisfies $::_git_version 1.6.3]} {
+	if {[package vcompare $::_git_version 1.6.3]} {
 		set ls_others [list --exclude-standard]
 	} else {
 		set ls_others [list --exclude-per-directory=.gitignore]
-- 
2.0.0.rc3.2.g998f840
Chris Packham· May 14, 2014, 07:46 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH] git-gui: use vcompare when comparing the git version

On 14/05/14 09:24, Jens Lehmann wrote:
Show 25 quoted lines
> Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
> the following error:
> 
>    No working directory ../../../<path>
> 
>    couldn't change working directory
>    to "../../../<path>": no such file or
>    directory
> 
> This is because "git rev-parse --show-toplevel" is only run when git gui
> sees a git version of at least 1.7.0 (which is the version in which the
> --show-toplevel option was introduced). But it uses vsatisfies to check
> that, which is documented to return false when the major version changes,
> which is not what we want here.
> 
> Change vsatisfies to vcompare when testing for a git version to avoid the
> problem when the major version changes (but still use vsatisfies in those
> places where the Tk version is checked). This is done for both the place
> that caused the reported bug and another spot where the git version is
> tested for another feature.
>
> Reported-by: Chris Packham <judge.packham@gmail.com>
> Reported-by: Yann Dirson <ydirson@free.fr>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---

Looks good to me (refer to previous comment about being rusty with tcl). More importantly

 Tested-by: Chris Packham <judge.packham@gmail.com>

There is the alternative I posted which just does away with the version checks (actually that only addressed one of the vcompare call sites).

There are also these checks that I guess are correct (if not inconsistent) but again who is still using git 1.5.3?

git-gui.sh:1098: >= 1.5.3 { lib/blame.tcl:800: if {[git-version >= 1.5.3]} { lib/blame.tcl:849: if {[git-version >= 1.5.3]} { lib/checkout_op.tcl:513: >= 1.5.3 {

Show 99 quoted lines
> 
> Am 07.05.2014 09:49, schrieb Chris Packham:
>> 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
> 
> Yup, looks like vsatisfies is doing just what it is supposed to (according
> to http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/package.n.html):
> 
>    package vsatisfies version1 version2
>        Returns 1 if scripts written for version2 will work unchanged
>        with version1 (i.e. version1 is equal to or greater than version2
>        and they both have the same major version number), 0 otherwise.
> 
> The bump in the major number from 1 to 2 makes vsatisfies assume that the
> version is not compatible anymore, I believe we should have used vcompare
> here and in another place.
> 
> 
>  git-gui.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/git-gui.sh b/git-gui.sh
> index cf2209b..ed2418b 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -1283,7 +1283,7 @@ load_config 0
>  apply_config
> 
>  # v1.7.0 introduced --show-toplevel to return the canonical work-tree
> -if {[package vsatisfies $_git_version 1.7.0]} {
> +if {[package vcompare $_git_version 1.7.0]} {
>  	if { [is_Cygwin] } {
>  		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
>  	} else {
> @@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
>  		close $fd
>  	}
> 
> -	if {[package vsatisfies $::_git_version 1.6.3]} {
> +	if {[package vcompare $::_git_version 1.6.3]} {
>  		set ls_others [list --exclude-standard]
>  	} else {
>  		set ls_others [list --exclude-per-directory=.gitignore]
> 
Jens Lehmann· May 14, 2014, 07:49 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH] git-gui: use vcompare when comparing the git version

Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise git gui will not work inside submodules anymore due to the major version number change from 1 to 2. I'd like to hear Pat's opinion on this; even though I think my patch is less risky (as it doesn't change behavior for pre-2 versions), he might like Chris' proposal better.

Am 13.05.2014 23:24, schrieb Jens Lehmann:
Show 124 quoted lines
> Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
> the following error:
> 
>    No working directory ../../../<path>
> 
>    couldn't change working directory
>    to "../../../<path>": no such file or
>    directory
> 
> This is because "git rev-parse --show-toplevel" is only run when git gui
> sees a git version of at least 1.7.0 (which is the version in which the
> --show-toplevel option was introduced). But it uses vsatisfies to check
> that, which is documented to return false when the major version changes,
> which is not what we want here.
> 
> Change vsatisfies to vcompare when testing for a git version to avoid the
> problem when the major version changes (but still use vsatisfies in those
> places where the Tk version is checked). This is done for both the place
> that caused the reported bug and another spot where the git version is
> tested for another feature.
> 
> Reported-by: Chris Packham <judge.packham@gmail.com>
> Reported-by: Yann Dirson <ydirson@free.fr>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
> 
> Am 07.05.2014 09:49, schrieb Chris Packham:
>> 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
> 
> Yup, looks like vsatisfies is doing just what it is supposed to (according
> to http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/package.n.html):
> 
>    package vsatisfies version1 version2
>        Returns 1 if scripts written for version2 will work unchanged
>        with version1 (i.e. version1 is equal to or greater than version2
>        and they both have the same major version number), 0 otherwise.
> 
> The bump in the major number from 1 to 2 makes vsatisfies assume that the
> version is not compatible anymore, I believe we should have used vcompare
> here and in another place.
> 
> 
>  git-gui.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/git-gui.sh b/git-gui.sh
> index cf2209b..ed2418b 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -1283,7 +1283,7 @@ load_config 0
>  apply_config
> 
>  # v1.7.0 introduced --show-toplevel to return the canonical work-tree
> -if {[package vsatisfies $_git_version 1.7.0]} {
> +if {[package vcompare $_git_version 1.7.0]} {
>  	if { [is_Cygwin] } {
>  		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
>  	} else {
> @@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
>  		close $fd
>  	}
> 
> -	if {[package vsatisfies $::_git_version 1.6.3]} {
> +	if {[package vcompare $::_git_version 1.6.3]} {
>  		set ls_others [list --exclude-standard]
>  	} else {
>  		set ls_others [list --exclude-per-directory=.gitignore]
> 
Junio C Hamano· May 14, 2014, 19:22 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH] git-gui: use vcompare when comparing the git version

Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 5 quoted lines
> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
> git gui will not work inside submodules anymore due to the major version
> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
> though I think my patch is less risky (as it doesn't change behavior for
> pre-2 versions), he might like Chris' proposal better.
Thanks; I share the same feeling.
Show 125 quoted lines
> Am 13.05.2014 23:24, schrieb Jens Lehmann:
>> Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
>> the following error:
>> 
>>    No working directory ../../../<path>
>> 
>>    couldn't change working directory
>>    to "../../../<path>": no such file or
>>    directory
>> 
>> This is because "git rev-parse --show-toplevel" is only run when git gui
>> sees a git version of at least 1.7.0 (which is the version in which the
>> --show-toplevel option was introduced). But it uses vsatisfies to check
>> that, which is documented to return false when the major version changes,
>> which is not what we want here.
>> 
>> Change vsatisfies to vcompare when testing for a git version to avoid the
>> problem when the major version changes (but still use vsatisfies in those
>> places where the Tk version is checked). This is done for both the place
>> that caused the reported bug and another spot where the git version is
>> tested for another feature.
>> 
>> Reported-by: Chris Packham <judge.packham@gmail.com>
>> Reported-by: Yann Dirson <ydirson@free.fr>
>> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
>> ---
>> 
>> Am 07.05.2014 09:49, schrieb Chris Packham:
>>> 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
>> 
>> Yup, looks like vsatisfies is doing just what it is supposed to (according
>> to http://www.astro.princeton.edu/~rhl/Tcl-Tk_docs/tcl/package.n.html):
>> 
>>    package vsatisfies version1 version2
>>        Returns 1 if scripts written for version2 will work unchanged
>>        with version1 (i.e. version1 is equal to or greater than version2
>>        and they both have the same major version number), 0 otherwise.
>> 
>> The bump in the major number from 1 to 2 makes vsatisfies assume that the
>> version is not compatible anymore, I believe we should have used vcompare
>> here and in another place.
>> 
>> 
>>  git-gui.sh | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/git-gui.sh b/git-gui.sh
>> index cf2209b..ed2418b 100755
>> --- a/git-gui.sh
>> +++ b/git-gui.sh
>> @@ -1283,7 +1283,7 @@ load_config 0
>>  apply_config
>> 
>>  # v1.7.0 introduced --show-toplevel to return the canonical work-tree
>> -if {[package vsatisfies $_git_version 1.7.0]} {
>> +if {[package vcompare $_git_version 1.7.0]} {
>>  	if { [is_Cygwin] } {
>>  		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
>>  	} else {
>> @@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
>>  		close $fd
>>  	}
>> 
>> -	if {[package vsatisfies $::_git_version 1.6.3]} {
>> +	if {[package vcompare $::_git_version 1.6.3]} {
>>  		set ls_others [list --exclude-standard]
>>  	} else {
>>  		set ls_others [list --exclude-per-directory=.gitignore]
>> 
Junio C Hamano· May 14, 2014, 21:49 UTC · re: Junio C Hamano · lore

Re: [GIT GUI PATCH] git-gui: use vcompare when comparing the git version

Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
>> git gui will not work inside submodules anymore due to the major version
>> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
>> though I think my patch is less risky (as it doesn't change behavior for
>> pre-2 versions), he might like Chris' proposal better.
>
> Thanks; I share the same feeling.

So after checking git://repo.or.cz/git-gui.git/ and seeing that I am not missing any commit from there, I tentatively created a fork of it, applied your patch and merged it somewhere on 'pu' that is close to 'next'. We may want to fast-track it to 2.0 without waiting for an Ack from Pat but let's give him one more day to respond.

Pat Thoyts· May 17, 2014, 12:23 UTC · re: Junio C Hamano · lore

Re: [GIT GUI PATCH] git-gui: use vcompare when comparing the git version

Junio C Hamano <gitster@pobox.com> writes:
Show 18 quoted lines
>Junio C Hamano <gitster@pobox.com> writes:
>
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
>>> git gui will not work inside submodules anymore due to the major version
>>> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
>>> though I think my patch is less risky (as it doesn't change behavior for
>>> pre-2 versions), he might like Chris' proposal better.
>>
>> Thanks; I share the same feeling.
>
>So after checking git://repo.or.cz/git-gui.git/ and seeing that I am
>not missing any commit from there, I tentatively created a fork of
>it, applied your patch and merged it somewhere on 'pu' that is close
>to 'next'.  We may want to fast-track it to 2.0 without waiting for
>an Ack from Pat but let's give him one more day to respond.
>

The analysis about the major version number being significant is correct. By default vsatisfies assumes that a major version number change means all lesser versions are incompatible. However, you can prevent that assumption using an unlimited check by appending a - (minus sign) to the version to yield an open ended range. Or by giving another range. So the only change required is to append a minus.

  package vsatisfies $::_git_version 1.7.0-
will suffice.
  package vsatisfies $::_git_version 1.7.0 2.0.0
would work but would cause failures when we arrive at git 3.0
-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
Jens Lehmann· May 17, 2014, 19:49 UTC · re: Pat Thoyts · lore

[GIT GUI PATCH v2] git-gui: tolerate major version changes when comparing the git version

Since git 2.0.0 starting git gui in a submodule using a gitfile fails with the following error:

   No working directory ../../../<path>
   couldn't change working directory
   to "../../../<path>": no such file or
   directory

This is because "git rev-parse --show-toplevel" is only run when git gui sees a git version of at least 1.7.0 (which is the version in which the --show-toplevel option was introduced). But "package vsatisfies" returns false when the major version changes, which is not what we want here.

Fix that for both places where the git version is checked using vsatifies by appending a '-' to the version number. This tells vsatisfies that a change of the major version is not considered to be a problem, as long as the new major version is larger. This is done for both the place that caused the reported bug and another spot where the git version is tested for another feature.

Reported-by: Chris Packham <judge.packham@gmail.com>
Reported-by: Yann Dirson <ydirson@free.fr>
Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 17.05.2014 14:23, schrieb Pat Thoyts:
Show 35 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>>
>>>> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
>>>> git gui will not work inside submodules anymore due to the major version
>>>> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
>>>> though I think my patch is less risky (as it doesn't change behavior for
>>>> pre-2 versions), he might like Chris' proposal better.
>>>
>>> Thanks; I share the same feeling.
>>
>> So after checking git://repo.or.cz/git-gui.git/ and seeing that I am
>> not missing any commit from there, I tentatively created a fork of
>> it, applied your patch and merged it somewhere on 'pu' that is close
>> to 'next'.  We may want to fast-track it to 2.0 without waiting for
>> an Ack from Pat but let's give him one more day to respond.
>>
> 
> The analysis about the major version number being significant is
> correct. By default vsatisfies assumes that a major version number
> change means all lesser versions are incompatible. However, you can
> prevent that assumption using an unlimited check by appending a - (minus
> sign) to the version to yield an open ended range. Or by giving another
> range. So the only change required is to append a minus.
> 
>   package vsatisfies $::_git_version 1.7.0-
> 
> will suffice.
> 
>   package vsatisfies $::_git_version 1.7.0 2.0.0
> 
> would work but would cause failures when we arrive at git 3.0

Thanks for the review! In this version I added the '-' to the version passed to vsatisfies and updated the commit message accordingly. I tested the result and it fixes the regression.

Junio, please replace my old version with this. In the first version I forgot to add a ">= 0" after the vcompare, which results in all versions that are /different/ than the one checked against pass the test. While that fixes the 2.0.0 regression, it will fail for git versions older than the version that is tested for. So my first attempt wasn't /that/ different from Chris' proposal ... :-/

 git-gui/git-gui.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index cf2209b..6a8907e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1283,7 +1283,7 @@ load_config 0
 apply_config

 # v1.7.0 introduced --show-toplevel to return the canonical work-tree
-if {[package vsatisfies $_git_version 1.7.0]} {
+if {[package vsatisfies $_git_version 1.7.0-]} {
 	if { [is_Cygwin] } {
 		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
 	} else {
@@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
 		close $fd
 	}

-	if {[package vsatisfies $::_git_version 1.6.3]} {
+	if {[package vsatisfies $::_git_version 1.6.3-]} {
 		set ls_others [list --exclude-standard]
 	} else {
 		set ls_others [list --exclude-per-directory=.gitignore]
-- 
1.8.3.1
Chris Packham· May 18, 2014, 00:31 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH v2] git-gui: tolerate major version changes when comparing the git version

On 18/05/14 07:49, Jens Lehmann wrote:
Show 102 quoted lines
> Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
> the following error:
> 
>    No working directory ../../../<path>
> 
>    couldn't change working directory
>    to "../../../<path>": no such file or
>    directory
> 
> This is because "git rev-parse --show-toplevel" is only run when git gui
> sees a git version of at least 1.7.0 (which is the version in which the
> --show-toplevel option was introduced). But "package vsatisfies" returns
> false when the major version changes, which is not what we want here.
> 
> Fix that for both places where the git version is checked using vsatifies
> by appending a '-' to the version number. This tells vsatisfies that a
> change of the major version is not considered to be a problem, as long as
> the new major version is larger. This is done for both the place that
> caused the reported bug and another spot where the git version is tested
> for another feature.
> 
> Reported-by: Chris Packham <judge.packham@gmail.com>
> Reported-by: Yann Dirson <ydirson@free.fr>
> Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
> 
> Am 17.05.2014 14:23, schrieb Pat Thoyts:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>>>
>>>>> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
>>>>> git gui will not work inside submodules anymore due to the major version
>>>>> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
>>>>> though I think my patch is less risky (as it doesn't change behavior for
>>>>> pre-2 versions), he might like Chris' proposal better.
>>>>
>>>> Thanks; I share the same feeling.
>>>
>>> So after checking git://repo.or.cz/git-gui.git/ and seeing that I am
>>> not missing any commit from there, I tentatively created a fork of
>>> it, applied your patch and merged it somewhere on 'pu' that is close
>>> to 'next'.  We may want to fast-track it to 2.0 without waiting for
>>> an Ack from Pat but let's give him one more day to respond.
>>>
>>
>> The analysis about the major version number being significant is
>> correct. By default vsatisfies assumes that a major version number
>> change means all lesser versions are incompatible. However, you can
>> prevent that assumption using an unlimited check by appending a - (minus
>> sign) to the version to yield an open ended range. Or by giving another
>> range. So the only change required is to append a minus.
>>
>>   package vsatisfies $::_git_version 1.7.0-
>>
>> will suffice.
>>
>>   package vsatisfies $::_git_version 1.7.0 2.0.0
>>
>> would work but would cause failures when we arrive at git 3.0
> 
> Thanks for the review! In this version I added the '-' to the version
> passed to vsatisfies and updated the commit message accordingly. I
> tested the result and it fixes the regression.
> 
> Junio, please replace my old version with this. In the first version
> I forgot to add a ">= 0" after the vcompare, which results in all
> versions that are /different/ than the one checked against pass the
> test. While that fixes the 2.0.0 regression, it will fail for git
> versions older than the version that is tested for. So my first
> attempt wasn't /that/ different from Chris' proposal ... :-/
> 
> 
>  git-gui/git-gui.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index cf2209b..6a8907e 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -1283,7 +1283,7 @@ load_config 0
>  apply_config
> 
>  # v1.7.0 introduced --show-toplevel to return the canonical work-tree
> -if {[package vsatisfies $_git_version 1.7.0]} {
> +if {[package vsatisfies $_git_version 1.7.0-]} {
>  	if { [is_Cygwin] } {
>  		catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
>  	} else {
> @@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
>  		close $fd
>  	}
> 
> -	if {[package vsatisfies $::_git_version 1.6.3]} {
> +	if {[package vsatisfies $::_git_version 1.6.3-]} {
>  		set ls_others [list --exclude-standard]
>  	} else {
>  		set ls_others [list --exclude-per-directory=.gitignore]
> 
Works for me.
Eric Sunshine· May 18, 2014, 03:01 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH v2] git-gui: tolerate major version changes when comparing the git version

On Sat, May 17, 2014 at 3:49 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
Show 15 quoted lines
> Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
> the following error:
>
>    No working directory ../../../<path>
>
>    couldn't change working directory
>    to "../../../<path>": no such file or
>    directory
>
> This is because "git rev-parse --show-toplevel" is only run when git gui
> sees a git version of at least 1.7.0 (which is the version in which the
> --show-toplevel option was introduced). But "package vsatisfies" returns
> false when the major version changes, which is not what we want here.
>
> Fix that for both places where the git version is checked using vsatifies
s/vsatifies/vsatisfies/
Show 94 quoted lines
> by appending a '-' to the version number. This tells vsatisfies that a
> change of the major version is not considered to be a problem, as long as
> the new major version is larger. This is done for both the place that
> caused the reported bug and another spot where the git version is tested
> for another feature.
>
> Reported-by: Chris Packham <judge.packham@gmail.com>
> Reported-by: Yann Dirson <ydirson@free.fr>
> Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> Am 17.05.2014 14:23, schrieb Pat Thoyts:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>>>
>>>>> Junio, I believe this issue needs to be fixed before 2.0 final. Otherwise
>>>>> git gui will not work inside submodules anymore due to the major version
>>>>> number change from 1 to 2. I'd like to hear Pat's opinion on this; even
>>>>> though I think my patch is less risky (as it doesn't change behavior for
>>>>> pre-2 versions), he might like Chris' proposal better.
>>>>
>>>> Thanks; I share the same feeling.
>>>
>>> So after checking git://repo.or.cz/git-gui.git/ and seeing that I am
>>> not missing any commit from there, I tentatively created a fork of
>>> it, applied your patch and merged it somewhere on 'pu' that is close
>>> to 'next'.  We may want to fast-track it to 2.0 without waiting for
>>> an Ack from Pat but let's give him one more day to respond.
>>>
>>
>> The analysis about the major version number being significant is
>> correct. By default vsatisfies assumes that a major version number
>> change means all lesser versions are incompatible. However, you can
>> prevent that assumption using an unlimited check by appending a - (minus
>> sign) to the version to yield an open ended range. Or by giving another
>> range. So the only change required is to append a minus.
>>
>>   package vsatisfies $::_git_version 1.7.0-
>>
>> will suffice.
>>
>>   package vsatisfies $::_git_version 1.7.0 2.0.0
>>
>> would work but would cause failures when we arrive at git 3.0
>
> Thanks for the review! In this version I added the '-' to the version
> passed to vsatisfies and updated the commit message accordingly. I
> tested the result and it fixes the regression.
>
> Junio, please replace my old version with this. In the first version
> I forgot to add a ">= 0" after the vcompare, which results in all
> versions that are /different/ than the one checked against pass the
> test. While that fixes the 2.0.0 regression, it will fail for git
> versions older than the version that is tested for. So my first
> attempt wasn't /that/ different from Chris' proposal ... :-/
>
>
>  git-gui/git-gui.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index cf2209b..6a8907e 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -1283,7 +1283,7 @@ load_config 0
>  apply_config
>
>  # v1.7.0 introduced --show-toplevel to return the canonical work-tree
> -if {[package vsatisfies $_git_version 1.7.0]} {
> +if {[package vsatisfies $_git_version 1.7.0-]} {
>         if { [is_Cygwin] } {
>                 catch {set _gitworktree [exec cygpath --windows [git rev-parse --show-toplevel]]}
>         } else {
> @@ -1539,7 +1539,7 @@ proc rescan_stage2 {fd after} {
>                 close $fd
>         }
>
> -       if {[package vsatisfies $::_git_version 1.6.3]} {
> +       if {[package vsatisfies $::_git_version 1.6.3-]} {
>                 set ls_others [list --exclude-standard]
>         } else {
>                 set ls_others [list --exclude-per-directory=.gitignore]
> --
> 1.8.3.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Junio C Hamano· May 19, 2014, 17:16 UTC · re: Jens Lehmann · lore

Re: [GIT GUI PATCH v2] git-gui: tolerate major version changes when comparing the git version

Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 10 quoted lines
> Am 17.05.2014 14:23, schrieb Pat Thoyts:
>>
>> The analysis about the major version number being significant is
>> correct. ...
>> 
>>   package vsatisfies $::_git_version 1.7.0-
>> 
>> will suffice.
>
> Junio, please replace my old version with this.
Thanks, both.  Will replace.

← back to recent threads