{"thread":{"id":"9633","subject":"Problem with git-gui and relative directories","startedAt":"2007-08-24T13:40:31Z","lastAt":"2007-08-25T08:15:25Z","messageCount":4,"participants":["David Kastrup","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51446","messageId":"868x81vynk.fsf@lola.quinscape.zz","threadId":"9633","inReplyTo":null,"subject":"Problem with git-gui and relative directories","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-24T13:40:31Z","receivedAt":"2007-08-24T13:40:31Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nDoing something like\n\nmkdir -p junk/woozle\ncd junk\ngit-init\ncd woozle\necho \"hooray\" > plop\ngit add plop\ngit commit -m \"x\"\ngit gui blame plop\n\nerrors out with\n\nfatal: cannot stat path woozle/plop: No such file or directory\n\nObviously, git-gui is confused about relative paths here.\n\n-- \nDavid Kastrup\n"},{"id":"51489","messageId":"20070825031834.GW27913@spearce.org","threadId":"9633","inReplyTo":"868x81vynk.fsf@lola.quinscape.zz","subject":"Re: Problem with git-gui and relative directories","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-25T03:18:35Z","receivedAt":"2007-08-25T03:18:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Kastrup wrote:\n> Doing something like\n...\n> errors out with\n> \n> fatal: cannot stat path woozle/plop: No such file or directory\n> \n> Obviously, git-gui is confused about relative paths here.\n\nYes, it is. I'm committing this, to be included in 0.8.2:\n\n-->8--\ngit-gui: Correct 'git gui blame' in a subdirectory\n\nDavid Kastrup pointed out that the following sequence was not\nworking as we had intended:\n\n $ cd lib\n $ git gui blame console.tcl\n fatal: cannot stat path lib/console.tcl: No such file or directory\n\nThe problem here was we disabled the chdir to the root of the\nworking tree when we are running with a \"bare allowed\" feature\nsuch as blame or browser, but we still kept the prefix we found via\n`git rev-parse --show-prefix`. This caused us to try and look for\nthe file \"console.tcl\" within the subdirectory but also include\nthe subdirectory's own path from the root of the working tree.\nThis is unlikely to succeed, unless the user just happened to have\na \"lib/lib/console.tcl\" file in the repository, in which case we\nwould produce the wrong result.\n\nIn the case of a bare repository we shouldn't get back a value from\n`rev-parse --show-prefix`, so really $_prefix should only be set\nto the non-empty string if we are in a working tree and we are in a\nsubdirectory of that working tree. If this is true we really want\nto always be at the top level of the working tree, as all paths are\naccessed as though they were relative to the top of the working tree.\nConverting $_prefix to a ../ sequence is a fairly simple approach\nto moving up the requisite levels.\n\nSigned-off-by: Shawn O. Pearce \n---\n git-gui.sh | 10 +++++++++-\n 1 files changed, 9 insertions(+), 1 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 743b7d4..fa30ccc 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -703,7 +703,15 @@ if {![file isdirectory $_gitdir]} {\n \terror_popup \"Git directory not found:\\n\\n$_gitdir\"\n \texit 1\n }\n-if {![is_enabled bare]} {\n+if {$_prefix ne {}} {\n+\tregsub -all {[^/]+/} $_prefix ../ cdup\n+\tif {[catch {cd $cdup} err]} {\n+\t\tcatch {wm withdraw .}\n+\t\terror_popup \"Cannot move to top of working directory:\\n\\n$err\"\n+\t\texit 1\n+\t}\n+\tunset cdup\n+} elseif {![is_enabled bare]} {\n \tif {[lindex [file split $_gitdir] end] ne {.git}} {\n \t\tcatch {wm withdraw .}\n \t\terror_popup \"Cannot use funny .git directory:\\n\\n$_gitdir\"\n-- \n1.5.3.rc6.17.g1911\n\n-- \nShawn.\n"},{"id":"51496","messageId":"85veb4dqhv.fsf@lola.goethe.zz","threadId":"9633","inReplyTo":"20070825031834.GW27913@spearce.org","subject":"Re: Problem with git-gui and relative directories","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-25T07:26:20Z","receivedAt":"2007-08-25T07:26:20Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Signed-off-by: Shawn O. Pearce \n> ---\n> git-gui.sh | 10 +++++++++-\n> 1 files changed, 9 insertions(+), 1 deletions(-)\n>\n> diff --git a/git-gui.sh b/git-gui.sh\n> index 743b7d4..fa30ccc 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -703,7 +703,15 @@ if {![file isdirectory $_gitdir]} {\n> \terror_popup \"Git directory not found:\\n\\n$_gitdir\"\n> \texit 1\n> }\n> -if {![is_enabled bare]} {\n> +if {$_prefix ne {}} {\n> +\tregsub -all {[^/]+/} $_prefix ../ cdup\n\nI don't like this approach. It assumes too much about the file system\nand cleanliness of paths. It does all of the following:\n\n/somedir/ -> /../\n/somedir -> /somedir\n//server/somedir -> //../somedir\n/somedir//someother -> /..//someother\n\nand so on. It can't deal with directory symlinks properly. And the\napproach does not scale to Windows and other systems with diverging\npath syntaxes at all.\n\nIsn't it possible to move to the workdir root for the purpose of\ninterpreting workdir root relative filenames?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51498","messageId":"20070825081525.GB18160@spearce.org","threadId":"9633","inReplyTo":"85veb4dqhv.fsf@lola.goethe.zz","subject":"Re: Problem with git-gui and relative directories","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-08-25T08:15:25Z","receivedAt":"2007-08-25T08:15:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"David Kastrup wrote:\n> \"Shawn O. Pearce\" writes:\n> > +if {$_prefix ne {}} {\n> > +\tregsub -all {[^/]+/} $_prefix ../ cdup\n> \n> I don't like this approach. It assumes too much about the file system\n> and cleanliness of paths. It does all of the following:\n> \n> /somedir/ -> /../\n> /somedir -> /somedir\n> //server/somedir -> //../somedir\n> /somedir//someother -> /..//someother\n\nOK, well, uh. Go read the manpage for `git-rev-parse` and focus\nin particular on the `--show-prefix` option of that command.\nIts output is what we are using here. Its very well defined within\nGit, and should have the same definition on all operating systems,\nincluding MinGW.\n\nAnd if the MinGW folks did something funny its only a translation\nof / to \\, in which case its easy enough for git-gui to make that\ndecision on its own based on what type of git it is running on.\n \n> and so on. It can't deal with directory symlinks properly.\n\nDepends on your definition of properly. Here git-gui does exactly\nwhat the C programs in core Git do, which is counter to what the\nshell scripts do. And people prefer the C behavior of going up\nthrough the real parents, ignoring the symlinks that were used to\nget to the directory the user started git-gui within.\n\n> And the\n> approach does not scale to Windows and other systems with diverging\n> path syntaxes at all.\n\nYes, it does. Because the format of --show-prefix is defined.\n\n> Isn't it possible to move to the workdir root for the purpose of\n> interpreting workdir root relative filenames?\n\nBecause I have always disagreed with the GIT_WORK_TREE mess.\nI think its insane to say \"I'm here in A, my repository is over\nthere in B and my files are here in C... now go run status!\".\nBut apparently its a use case.\n\nI guess I could use `git rev-parse --show-cdup` and that would just\nhandle this case. But that's YAFAE (Yet Another Fork And Exec).\n\n-- \nShawn.\n"}]}