{"thread":{"id":"11104","subject":"Incorrect git-blame result if I use full path to file","startedAt":"2007-12-03T00:52:36Z","lastAt":"2007-12-06T06:12:34Z","messageCount":21,"participants":["Anatol Pomozov","Junio C Hamano","Jeff King","Robin Rosenberg","Linus Torvalds","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61701","messageId":"3665a1a00712021652tbdfe9d1tdc4575d225bfed36@mail.gmail.com","threadId":"11104","inReplyTo":null,"subject":"Incorrect git-blame result if I use full path to file","fromName":"Anatol Pomozov","fromEmail":"anatol.pomozov@gmail.com","sentAt":"2007-12-03T00:52:36Z","receivedAt":"2007-12-03T00:52:36Z","isPatch":false,"sender":{"key":"anatol.pomozov@gmail.com","avatar":"https://gravatar.com/avatar/71fc20093402ce987148294ec0999d025209e52da6762789ff248cf5c317645f?d=mp&s=160"},"body":"Hi, all.\n\nI just start learning git and I found a bug (but sorry if the\nfunctionality I am trying to blame as a bug not actually bug and it\nwas made by intention)\n\nThe problem is that git-blame returns incorrect result if you use full\npath for files.\n\nHere is an example script that generates repo.\n\n#go to empty dir\ngit init\necho \"On master\" >> master.txt\ngit add master.txt\ngit commit -m \"First commit\"\necho \"On master\" >> master.txt\ngit commit -a -m \"Second commit\"\necho \"On master\" >> master.txt\n\n\nNow lets do blame for master.txt\nanatol:repo $ git blame master.txt\n^69bce74 (Anatol Pomozov    2007-12-02 16:44:07 -0800 1) On master\n4e2bbde4 (Anatol Pomozov    2007-12-02 16:44:15 -0800 2) On master\n00000000 (Not Committed Yet 2007-12-02 16:44:27 -0800 3) On master\n\nIt is exaclty what we expect. But lets try full path for master.txt\n$pwd\n/personal/sources/learn/gitea/repo\n$git blame /personal/sources/learn/gitea/repo/master.txt\n^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 1) On master\n^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 2) On master\n^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 3) On master\n\n\nNow git shows that all lines in the file were changed by the first\ncommit and that it does not true.\n\n-- \nanatol\n"},{"id":"61707","messageId":"7vhcj0seok.fsf@gitster.siamese.dyndns.org","threadId":"11104","inReplyTo":"3665a1a00712021652tbdfe9d1tdc4575d225bfed36@mail.gmail.com","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T02:19:23Z","receivedAt":"2007-12-03T02:19:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Anatol Pomozov\" <anatol.pomozov@gmail.com> writes:\n\n> I just start learning git and I found a bug (but sorry if the\n> functionality I am trying to blame as a bug not actually bug and it\n> was made by intention)\n\nI think it is rather a sloppy error checking than a bug.  It should be\nthrowing a stone back at you when you feed it a full path, or converting\nit back to work tree relative path before using.\n"},{"id":"61708","messageId":"20071203022729.GD8322@coredump.intra.peff.net","threadId":"11104","inReplyTo":"3665a1a00712021652tbdfe9d1tdc4575d225bfed36@mail.gmail.com","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-03T02:27:29Z","receivedAt":"2007-12-03T02:27:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 02, 2007 at 04:52:36PM -0800, Anatol Pomozov wrote:\n\n> I just start learning git and I found a bug (but sorry if the\n> functionality I am trying to blame as a bug not actually bug and it\n> was made by intention)\n\nSome of both, I think. :)\n\n> It is exaclty what we expect. But lets try full path for master.txt\n> $pwd\n> /personal/sources/learn/gitea/repo\n> $git blame /personal/sources/learn/gitea/repo/master.txt\n> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 1) On master\n> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 2) On master\n> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 3) On master\n\nWe talk about many git commands taking \"files\" or \"paths\" but really\nthey are git \"pathspecs\", meaning a path specifier that is relative to\nthe repository root, and which is generally used for limiting the parts\nof the history we are looking at.\n\nSo I think what is happening is that git-blame is looking for content\nfrom /personal/sources/..., which of course as a git pathspec doesn't\nmatch any of the files. So everything ends up being blamed on\n'^69bce74' (which really means \"beyond where we started looking\"). But\nof course it still finds the content to try blaming in the first place,\nbecause in that instance it treats /personal/sources/... as a file to be\nopened.\n\nIOW, it's not intended for users to use absolute paths in this way.\nHowever, the results for git-blame are obviously quite confusing. It\nmight be worth fixing, but I suspect there are many more such traps\nwaiting in other commands. I wonder if it would make sense to reject\npathspecs starting with '/' entirely, which would at least give us a\nsaner error message (and I can't think of a time when such a pathspec\nwould be useful)? Even more useful would be to convert\n/path/to/repo/file to 'file' internally.\n\n-Peff\n"},{"id":"61709","messageId":"20071203022831.GE8322@coredump.intra.peff.net","threadId":"11104","inReplyTo":"7vhcj0seok.fsf@gitster.siamese.dyndns.org","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-03T02:28:31Z","receivedAt":"2007-12-03T02:28:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 02, 2007 at 06:19:23PM -0800, Junio C Hamano wrote:\n\n> I think it is rather a sloppy error checking than a bug.  It should be\n> throwing a stone back at you when you feed it a full path, or converting\n> it back to work tree relative path before using.\n\nI think it's not the only place. Doing \"git diff /path/to/repo/file\"\nsilently produces an empty diff, even if there are changes in the file.\n\n-Peff\n"},{"id":"61712","messageId":"7v4pf0sdp7.fsf@gitster.siamese.dyndns.org","threadId":"11104","inReplyTo":"20071203022729.GD8322@coredump.intra.peff.net","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T02:40:36Z","receivedAt":"2007-12-03T02:40:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> IOW, it's not intended for users to use absolute paths in this way.\n> However, the results for git-blame are obviously quite confusing. It\n> might be worth fixing, but I suspect there are many more such traps\n> waiting in other commands. I wonder if it would make sense to reject\n> pathspecs starting with '/' entirely, which would at least give us a\n> saner error message (and I can't think of a time when such a pathspec\n> would be useful)?\n\nAll correct, except...\n\n> Even more useful would be to convert\n> /path/to/repo/file to 'file' internally.\n\n... that might help \"cut & paste from file manager\" people, and I think\nwe had comment session for such a patch recently on the list.\n\nSorry, but I lost track of that the current status of that patch.  Did\nit die?\n"},{"id":"61714","messageId":"20071203024916.GA11003@coredump.intra.peff.net","threadId":"11104","inReplyTo":"7v4pf0sdp7.fsf@gitster.siamese.dyndns.org","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-03T02:49:16Z","receivedAt":"2007-12-03T02:49:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 02, 2007 at 06:40:36PM -0800, Junio C Hamano wrote:\n\n> > Even more useful would be to convert\n> > /path/to/repo/file to 'file' internally.\n> \n> ... that might help \"cut & paste from file manager\" people, and I think\n> we had comment session for such a patch recently on the list.\n> \n> Sorry, but I lost track of that the current status of that patch.  Did\n> it die?\n\nI didn't pay attention to it originally, but I assume you mean the\nrecent patch from Robin Rosenberg (cc'd). Looking it over, I see one\nobvious omission: there is no canonicalization of the paths. IOW, I\nthink it will break in the presence of symlinks (if I specify\n/path/to/repo/file, /path/to is a symlink to /other/path, I think the\nworktree will end up as /other/path/repo, and fail a string comparison\nwith /path/to/repo).\n\n-Peff\n"},{"id":"61741","messageId":"200712030755.37038.robin.rosenberg@dewire.com","threadId":"11104","inReplyTo":"20071203024916.GA11003@coredump.intra.peff.net","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-12-03T06:55:35Z","receivedAt":"2007-12-03T06:55:35Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 03 december 2007 skrev Jeff King:\n> On Sun, Dec 02, 2007 at 06:40:36PM -0800, Junio C Hamano wrote:\n> \n> > > Even more useful would be to convert\n> > > /path/to/repo/file to 'file' internally.\n> > \n> > ... that might help \"cut & paste from file manager\" people, and I think\n> > we had comment session for such a patch recently on the list.\n> > \n> > Sorry, but I lost track of that the current status of that patch.  Did\n> > it die?\n> \n> I didn't pay attention to it originally, but I assume you mean the\n> recent patch from Robin Rosenberg (cc'd). Looking it over, I see one\n> obvious omission: there is no canonicalization of the paths. IOW, I\n> think it will break in the presence of symlinks (if I specify\n> /path/to/repo/file, /path/to is a symlink to /other/path, I think the\n> worktree will end up as /other/path/repo, and fail a string comparison\n> with /path/to/repo).\n\nNo it didn't die, it's just not worked on too often. I notes, among, other things\nthat it's test cases were not correct, besides needing more tests.\n\nSymlinks were not covered.\n\n-- robin\n"},{"id":"61791","messageId":"alpine.LFD.0.9999.0712030922250.8458@woody.linux-foundation.org","threadId":"11104","inReplyTo":"7vhcj0seok.fsf@gitster.siamese.dyndns.org","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-03T17:26:30Z","receivedAt":"2007-12-03T17:26:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 2 Dec 2007, Junio C Hamano wrote:\n> \"Anatol Pomozov\" <anatol.pomozov@gmail.com> writes:\n> >\n> > I just start learning git and I found a bug (but sorry if the\n> > functionality I am trying to blame as a bug not actually bug and it\n> > was made by intention)\n> \n> I think it is rather a sloppy error checking than a bug.  It should be\n> throwing a stone back at you when you feed it a full path, or converting\n> it back to work tree relative path before using.\n\nHow about this patch?\n\nIt makes \"get_pathspec()\" make all the paths it returns relative, if it \ncan. HOWEVER! I think it should actually die() if it sees an absolute path \nthat it cannot convert (because it really cannot do anything sane about \nit), but I commented that out for now because that requires some test case \nchange: right now we actually have a few test cases for insane filename \narguments, and they expect the old behaviour.\n\nComments? This changes behaviour subtly (and if we enable the \"die(..)\" \nlogic, not-so-subtly), but I think that in any case where it changes \nbehaviour, the new behaviour would be an improvement, and the old one \nwould be nonsensical (ie you get *some* results with an absolute pathname, \njust not the ones you'd expect!)\n\nNote the die() comment in the bad case in \"make_relative()\".\n\n\t\tLinus\n---\n setup.c |   34 +++++++++++++++++++++++++++++++++-\n 1 files changed, 33 insertions(+), 1 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 2c7b5cb..fadf4ee 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -111,11 +111,26 @@ void verify_non_filename(const char *prefix, const char *arg)\n \t\tdie(\"'%s': %s\", arg, strerror(errno));\n }\n \n+static const char *make_relative(const char *file, const char *pwd, int pwdlen)\n+{\n+\tif (strncmp(file, pwd, pwdlen))\n+\t\tgoto bad;\n+\tif (file[pwdlen] != '/')\n+\t\tgoto bad;\n+\treturn file + pwdlen + 1;\n+\n+bad:\n+\t/* Should we die() here or just do a \"return file\"? */\n+\t/* die(\"pathname '%s' is not in the repository\", file); */\n+\treturn file;\n+}\n+\n const char **get_pathspec(const char *prefix, const char **pathspec)\n {\n+\tconst char *pwd;\n \tconst char *entry = *pathspec;\n \tconst char **p;\n-\tint prefixlen;\n+\tint prefixlen, pwdlen;\n \n \tif (!prefix && !entry)\n \t\treturn NULL;\n@@ -127,9 +142,26 @@ const char **get_pathspec(const char *prefix, const char **pathspec)\n \t\treturn spec;\n \t}\n \n+\tpwd = NULL;\n+\tpwdlen = 0;\n+\tp = pathspec;\n+\tdo {\n+\t\tif (*entry == '/') {\n+\t\t\tif (!pwd) {\n+\t\t\t\tchar buffer[PATH_MAX + 1];\n+\t\t\t\tif (!getcwd(buffer, sizeof(buffer)))\n+\t\t\t\t\tbreak;\n+\t\t\t\tpwd = buffer;\n+\t\t\t\tpwdlen = strlen(buffer);\n+\t\t\t}\n+\t\t\t*p = make_relative(entry, pwd, pwdlen);\n+\t\t}\n+\t} while ((entry = *++p) != NULL);\n+\n \t/* Otherwise we have to re-write the entries.. */\n \tp = pathspec;\n \tprefixlen = prefix ? strlen(prefix) : 0;\n+\tentry = *p;\n \tdo {\n \t\t*p = prefix_path(prefix, prefixlen, entry);\n \t} while ((entry = *++p) != NULL);\n"},{"id":"61798","messageId":"Pine.LNX.4.64.0712031807410.27959@racer.site","threadId":"11104","inReplyTo":"alpine.LFD.0.9999.0712030922250.8458@woody.linux-foundation.org","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-03T18:09:05Z","receivedAt":"2007-12-03T18:09:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Linus Torvalds wrote:\n\n> It [the patch] makes \"get_pathspec()\" make all the paths it returns \n> relative, if it can. HOWEVER! I think it should actually die() if it \n> sees an absolute path that it cannot convert (because it really cannot \n> do anything sane about it), but I commented that out for now because \n> that requires some test case change: right now we actually have a few \n> test cases for insane filename arguments, and they expect the old \n> behaviour.\n\nI have the slight suspicion that this could break diff --no-index.  And it \ndoes not contain any symlink resolution, right?\n\nCiao,\nDscho\n"},{"id":"61806","messageId":"alpine.LFD.0.9999.0712031012280.8458@woody.linux-foundation.org","threadId":"11104","inReplyTo":"Pine.LNX.4.64.0712031807410.27959@racer.site","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-03T18:13:51Z","receivedAt":"2007-12-03T18:13:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Dec 2007, Johannes Schindelin wrote:\n> \n> I have the slight suspicion that this could break diff --no-index.\n\nQuite possible.\n\n> And it does not contain any symlink resolution, right?\n\nThat's correct, and by design. If you give a path where the absolute part \nof the path contains some symlink that eventually gets you to the right \npoint, you get screwed. That's part of why I'd _prefer_ to do the \"die()\" \npart, so that you get screwed with a nice error message, rather than being \nscrewed by getting unexpected results!\n\n\t\t\tLinus\n"},{"id":"61805","messageId":"alpine.LFD.0.9999.0712031014110.8458@woody.linux-foundation.org","threadId":"11104","inReplyTo":"alpine.LFD.0.9999.0712031012280.8458@woody.linux-foundation.org","subject":"Re: Incorrect git-blame result if I use full path to file","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-03T18:19:42Z","receivedAt":"2007-12-03T18:19:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Dec 2007, Linus Torvalds wrote:\n> \n> On Mon, 3 Dec 2007, Johannes Schindelin wrote:\n> > \n> > I have the slight suspicion that this could break diff --no-index.\n> \n> Quite possible.\n\nSide note: another issue (for the particular case that Anatol hit) is that \nthis patch obviously only helps for commands that actually use \n\"get_pathspec()\" (usually through doing all the common argument setup \nstuff). So \"git log\" and friends work fine.\n\nHOWEVER. \"git blame\" has its own argument parsing that doesn't use any of \nthe common routines, and thus the behaviour that Anatol complained about \nisn't fixed at all by the patch.\n\nI think that should be fixed by just making git blame use the standard \narguments (which in turn may involve having to teach the *other* commands \nabout the \"-S <revs-file>\" and \"-L n,m\" forms! I think those are why it \ndoes its own specialized parsing), but obviously git-blame could also be \ntought to just do \"get_pathspec()\" too.\n\n\t\tLinus\n"},{"id":"61816","messageId":"200712032153.31322.robin.rosenberg.lists@dewire.com","threadId":"11104","inReplyTo":"200712030755.37038.robin.rosenberg@dewire.com","subject":"[PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-12-03T20:53:30Z","receivedAt":"2007-12-03T20:53:30Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"This patch makes it possible to drag files and directories from\na graphical browser and drop them onto a shell and feed them\nto common git operations without editing away the path to the\nroot of the work tree.\n\nSigned-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n---\n\nI will not surrender to the fierce competion on this subject. Here is an update\nwith hopefully correct test cases this time. (Linus. your code did not pass). Like Linus,\nthis code does not resolve symlinks, but I forgot to state that it is by design. It\nsolves my problem and happens to solve Anatols problem (actually the same since\npassing absolute file names to blame is my most important use case).\n\n-- robin\n\n builtin-blame.c       |    4 +-\n setup.c               |   53 +++++++++++++++++++++++\n t/t3904-abspatharg.sh |  112 +++++++++++++++++++++++++++++++++++++++++++++++++\n 3 files changed, 166 insertions(+), 3 deletions(-)\n create mode 100755 t/t3904-abspatharg.sh\n\ndiff --git a/builtin-blame.c b/builtin-blame.c\nindex c158d31..b905dcf 100644\n--- a/builtin-blame.c\n+++ b/builtin-blame.c\n@@ -1880,9 +1880,7 @@ static unsigned parse_score(const char *arg)\n \n static const char *add_prefix(const char *prefix, const char *path)\n {\n-\tif (!prefix || !prefix[0])\n-\t\treturn path;\n-\treturn prefix_path(prefix, strlen(prefix), path);\n+\treturn prefix_path(prefix, prefix ? strlen(prefix) : 0, path);\n }\n \n /*\ndiff --git a/setup.c b/setup.c\nindex 2c7b5cb..1f0ec79 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -4,9 +4,62 @@\n static int inside_git_dir = -1;\n static int inside_work_tree = -1;\n \n+static\n+const char *strip_work_tree_path(const char *prefix, int len, const char *path)\n+{\n+\tconst char *work_tree = get_git_work_tree();\n+\tint n = strlen(work_tree);\n+\n+\tif (strncmp(path, work_tree, n))\n+\t\treturn path;\n+\n+\tif (!prefix && !path[n])\n+\t\treturn path + n;\n+\n+\tif (!prefix) {\n+\t\tif (path[n] == '/')\n+\t\t\treturn path + n + 1;\n+\t\telse\n+\t\t\tif (path[n])\n+\t\t\t\treturn path;\n+\t\t\telse\n+\t\t\t\treturn path + n;\n+\t}\n+\n+\tif (prefix && !path[n])\n+\t\treturn path;\n+\n+\tif (strncmp(path + n + 1, prefix, len - 1)) {\n+\t\tfprintf(stderr,\"prefix mismatch\\n\");\n+\t\tchar *np;\n+\t\tint i;\n+\t\tint d=0;\n+\t\tfor (i = 0; i < len; ++i)\n+\t\t\tif (prefix[i] == '/')\n+\t\t\t\td++;\n+\t\tnp = xmalloc(strlen(path + n) + d * 3 + 1);\n+\t\tfor (i=0; i < d * 3; i += 3)\n+\t\t\tstrcpy(np + i, \"../\");\n+\t\tstrcpy(np + i, path + n + 1);\n+\t\tpath = np;\n+\t\treturn np;\n+\t}\n+\n+\tif (path[len + n] == '/')\n+\t\treturn path + len + n + 1;\n+\telse\n+\t\tif (path[len + n])\n+\t\t\treturn path;\n+\t\telse\n+\t\t\treturn path + len + n;\n+}\n+\n const char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n+\tif (is_absolute_path(path))\n+\t\tpath = strip_work_tree_path(prefix, len, path);\n+\n \tfor (;;) {\n \t\tchar c;\n \t\tif (*path != '.')\ndiff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh\nnew file mode 100755\nindex 0000000..47f1222\n--- /dev/null\n+++ b/t/t3904-abspatharg.sh\n@@ -0,0 +1,112 @@\n+#!/bin/sh\n+#\n+# Copyright (C) 2007 Robin Rosenberg\n+#\n+\n+test_description='Test absolute filename arguments to various git\n+commands.  Absolute arguments pointing to a location within the git\n+work tree should behave the same as relative arguments.  '\n+\n+. ./test-lib.sh\n+\n+test_expect_success 'add files using absolute path names' '\n+\techo a >afile &&\n+\techo b >bfile &&\n+\tgit-add afile &&\n+\tgit-add \"$(pwd)/bfile\" &&\n+\ttest \"afile bfile\" = \"$(echo $(git ls-files))\"\n+\tmkdir x &&\n+\t(\n+\t\tcd x &&\n+\t\techo c >cfile &&\n+\t\techo d >dfile &&\n+\t\tgit-add cfile &&\n+\t\tgit-add \"$(pwd)\"\n+\t) &&\n+\ttest \"afile bfile x/cfile x/dfile\" = \"$(echo $(git ls-files))\" &&\n+\tgit ls-files x >f1 &&\n+\tgit ls-files \"$(pwd)/x\" >f2 &&\n+\tdiff -u f1 f2\n+'\n+\n+test_expect_success 'commit using absolute path names' '\n+\tgit commit -m \"foo\" &&\n+\techo aa >>bfile &&\n+\tgit commit -m \"aa\" \"$(pwd)/bfile\"\n+'\n+\n+test_expect_success 'log using absolute path names' '\n+\techo bb >>bfile &&\n+\tgit commit -m \"bb\" $(pwd)/bfile &&\n+\n+\tgit log bfile >f1.txt &&\n+\tgit log \"$(pwd)/bfile\" >f2.txt &&\n+\tdiff -u f1.txt f2.txt\n+'\n+\n+test_expect_success 'blame using absolute path names' '\n+\tgit blame bfile >f1.txt &&\n+\tgit blame \"$(pwd)/bfile\" >f2.txt &&\n+\tdiff -u f1.txt f2.txt\n+'\n+\n+test_expect_success 'diff using absolute path names' '\n+\tgit diff HEAD HEAD^ -- \"$(pwd)/bfile\" >f1.txt &&\n+\tgit diff HEAD HEAD^ -- bfile >f2.txt &&\n+\tdiff -u f1.txt f2.txt\n+'\n+\n+test_expect_success 'rm using absolute path names' '\n+\tgit rm \"$(pwd)/afile\" \"$(pwd)/x/cfile\" &&\n+\ttest \"bfile x/dfile\" = \"$(echo $(git ls-files))\"\n+'\n+\n+test_expect_success 'mv using absolute path names' '\n+\tgit reset --hard &&\n+\tgit mv \"$(pwd)/afile\" \"$(pwd)/dfile\" &&\n+\ttest \"bfile dfile x/cfile x/dfile\" = \"$(echo $(git ls-files))\" &&\n+\tgit mv \"$(pwd)/dfile\" afile &&\n+\ttest \"afile bfile x/cfile x/dfile\" = \"$(echo $(git ls-files))\"\n+'\n+\n+test_expect_success 'show using absolute path names' '\n+\tgit reset --hard &&\n+\tgit show \"$(pwd)/bfile\" >f1.txt &&\n+\tgit show bfile >f2.txt &&\n+\tdiff -u f1.txt f2.txt\n+'\n+\n+test_expect_success 'add path in parent directory' '\n+\t(\n+\t\td1=\"$(pwd)/x\"\n+\t\td2=\"$(pwd)/x/y\"\n+\t\tmkdir -p x/y &&\n+\t\techo hello1 >x/fa &&\n+\t\techo hello2 >x/y/fb &&\n+\t\tcd x/y &&\n+\t\tgit add \"$d1/fa\" \"$d2/fb\"\n+\t) &&\n+\ttest \"afile bfile x/cfile x/dfile x/fa x/y/fb\" = \"$(echo $(git ls-files))\"\n+'\n+\n+test_expect_success 'add a parent directory' '\n+\t(\n+\t\td1=\"$(pwd)/a\"\n+\t\td2=\"$(pwd)/a/b\"\n+\t\td3=\"$(pwd)/a/b/c\"\n+\t\tmkdir -p a/b/c\n+\t\techo helloa >a/a1 &&\n+\t\techo hellob >a/b/b1 &&\n+\t\techo helloc >a/b/c/c1 &&\n+\t\tcd a/b/c &&\n+\t\tgit add \"$d2\"\n+\t) &&\n+\ttest \"a/b/b1 a/b/c/c1 afile bfile x/cfile x/dfile x/fa x/y/fb\" = \"$(echo $(git ls-files))\"\n+'\n+\n+test_expect_failure 'add a directory outside the work tree' '\n+\td1=\"(cd .. ; pwd)\" &&\n+\tgit add \"$d1\"\n+'\n+\n+test_done\n-- \n1.5.3.5.1.gb2df9\n"},{"id":"61835","messageId":"7vr6i3e5zl.fsf@gitster.siamese.dyndns.org","threadId":"11104","inReplyTo":"200712032153.31322.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-03T23:03:10Z","receivedAt":"2007-12-03T23:03:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:\n\n> I will not surrender to the fierce competion on this subject. Here is\n> an update with hopefully correct test cases this time.\n\nYay, that's the spirit!\n\n> ... Like Linus, this code does not resolve symlinks,\n> but I forgot to state that it is by design.\n\nPerhaps state it in the commit log message?\n\n>  static const char *add_prefix(const char *prefix, const char *path)\n>  {\n> +\treturn prefix_path(prefix, prefix ? strlen(prefix) : 0, path);\n>  }\n\nOk; prefix_path can get NULL prefix (not complaining; just a reminder in\nthe following discussion).\n\n> diff --git a/setup.c b/setup.c\n> index 2c7b5cb..1f0ec79 100644\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -4,9 +4,62 @@\n>  static int inside_git_dir = -1;\n>  static int inside_work_tree = -1;\n>  \n> +static\n> +const char *strip_work_tree_path(const char *prefix, int len, const char *path)\n\nStyle.  \"static\" not on its own line.\n\n> +{\n> +\tconst char *work_tree = get_git_work_tree();\n> +\tint n = strlen(work_tree);\n\nPreconditions.\n\n * prefix could be NULL or path to the subdirectory the user's\n   non-absolute path should be relative to, expressed as a relative path\n   to the top of the work tree, including a trailing slash.  len is the\n   length of the prefix string.\n\n * path was determined by the caller to be absolute.\n\n * It is assumed that get_git_work_tree() always gives absolute path,\n   and without trailing slash.\n\n * Does prefix always NULL if we are at the top, and never \"\", I wonder.\n   But lets assume that, too.\n\n> +\tif (strncmp(path, work_tree, n))\n> +\t\treturn path;\n\nIf the given path is outside the work tree, return absolute as-is.\nAfter this point we know path matches the work tree\n\n> +\tif (!prefix && !path[n])\n> +\t\treturn path + n;\n\nIf we are at the top of the work tree and path names the top of the work\ntree, then we return \"\".\n\n> +\tif (!prefix) {\n> +\t\tif (path[n] == '/')\n> +\t\t\treturn path + n + 1;\n\nIf we are at the top of the work tree and the path names the top of the\nwork tree followed by a slash and then something, that is a path inside\nthe work tree.  Return relative to the top of the work tree.\n\n> +\t\telse\n> +\t\t\tif (path[n])\n> +\t\t\t\treturn path;\n> +\t\t\telse\n> +\t\t\t\treturn path + n;\n> +\t}\n\nStyle.  \"else if\" would give you shallower indentation.  We know path[n]\nwas not slash, and if it is not NUL then path is not inside the work\ntree but is a neighbour (e.g. worktree is /a/b and path is /a/bc).\nReturn absolute.  Otherwise the path names the top of the work tree\nitself so we return \"\".\n\nNow at this point, we know we are in a subdirectory, because the above\nif (!prefix) part always return.  So the test for prefix here is\nunnecessary.\n\n> +\tif (prefix && !path[n])\n> +\t\treturn path;\n\nIf we are in a subdirectory, and path names the top of the work tree, we\nreturn it as-is (i.e. absolute).  This feels a bit inconsistent with the\npart that follows, which tries to make things relative by using \"../\",\ndoesn't it?\n\n> +\tif (strncmp(path + n + 1, prefix, len - 1)) {\n\nFor !prefix case we have determined path is not merely a neighbour, but\nwe haven't checked that in this codepath.  If the parameters were like\nthis:\n\n\tpath      = /axbc/e\n        work_tree = /a\n\tn         = 2\n        prefix    =    bc/\n\tlen       = 3\n\nthis check says \"fine, path is under prefix and we won't add ../\nuplevels\".  You need to have\n\n\tif (path[n] != '/')\n        \treturn path;\n\nbefore this strncmp() for it to work, don't you?\n\nIn addition, by comparing (len - 1) excluding the trailing slash of\nprefix, I think you would let\n\n\tpath      = /a/bcye\n\nslip through as well.  That is inside the work_tree but outside of your\nprefix.\n\n> +\t\tfprintf(stderr,\"prefix mismatch\\n\");\n\nStray debugging fprintf.\n\n> +\t\tchar *np;\n> +\t\tint i;\n> +\t\tint d=0;\n\nStyle \"d = 0\" (and \"decl after statement\").\n\n> +\t\tfor (i = 0; i < len; ++i)\n\nStyle.  Distracts the reader by forcing him to wonder needlessly if\nthere is a particular reason for pre-increment of i instead of the usual\npost-increment.\n\n> +\t\t\tif (prefix[i] == '/')\n> +\t\t\t\td++;\n> +\t\tnp = xmalloc(strlen(path + n) + d * 3 + 1);\n\nAt this point (assuming that the above if (strncmp()) rejected the path\noutside the prefix correctly), we know that we would need to go d levels\nup to reach the top of the work tree.\n\n> +\t\tfor (i=0; i < d * 3; i += 3)\n\nStyle. \"i = 0\".\n\n> +\t\t\tstrcpy(np + i, \"../\");\n> +\t\tstrcpy(np + i, path + n + 1);\n\nAs path+n+1 is relative to the work tree, this will make it relative,\nwhich is good.\n\n> +\t\tpath = np;\n> +\t\treturn np;\n> +\t}\n\nAssuming the if (strncmp()) above correctly handled the path outside\nprefix, we are dealing with the path that is inside prefix at this\npoint.  (len+n) is the length of the prefix directory expressed as an\nabsolute path.\n\n> +\tif (path[len + n] == '/')\n> +\t\treturn path + len + n + 1;\n\nSo strip the absolute prefix would make the result relative to the\nprefix directory.  Nice.\n\n> +\telse\n> +\t\tif (path[len + n])\n> +\t\t\treturn path;\n\nThe same comment on \"else if\" applies.  path[len+n] was not slash so\npath was not inside the prefix after all.  Oops?  The \"if outside\nprefix we uplevel with ../\" logic above should have handled this case\nand we should not be here.\n\n> +\t\telse\n> +\t\t\treturn path + len + n;\n> +}\n\npath[len+n] was NUL, which means taht the user named the prefix\ndirectory, and we return \"\".\n\nIsn't this _overly_ complicated?  I think what this function wants to do\nis:\n\n * See if path is outside the work tree, and return absolute if so.\n\n * Come up with the absolute path for the prefix (if NULL then that is\n   the same as work tree) directory, without a trailing slash, and call\n   it X.\n\n * Is path the same as the X?  If so, \"\" is what you want.\n\n * Is path a prefix of the \"X/\"?  If so strip \"X/\" and return.\n\n * Find the longuest common leading directory of path and \"X/\" and call\n   it \"C/\".  Note that this is guaranteed to be inside work tree because\n   we rejected paths outside work tree upfront.\n\n * Count slashes between \"C/\" and \"X/\" and come up with necessary\n   uplevel \"../\".  Strip \"C/\" from path and prepend the uplevel.\n"},{"id":"61849","messageId":"20071204014326.GA21358@coredump.intra.peff.net","threadId":"11104","inReplyTo":"200712032153.31322.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-04T01:43:27Z","receivedAt":"2007-12-04T01:43:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:\n\n> code did not pass). Like Linus, this code does not resolve symlinks,\n> but I forgot to state that it is by design. It solves my problem and\n\nBy design meaning \"I didn't feel like implemening it because I do not\npersonally care\" or \"I have some reason not to resolve symlinks\"?\n\n-Peff\n"},{"id":"61856","messageId":"Pine.LNX.4.64.0712040216220.27959@racer.site","threadId":"11104","inReplyTo":"20071204014326.GA21358@coredump.intra.peff.net","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-04T02:17:40Z","receivedAt":"2007-12-04T02:17:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Jeff King wrote:\n\n> On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:\n> \n> > code did not pass). Like Linus, this code does not resolve symlinks,\n> > but I forgot to state that it is by design. It solves my problem and\n> \n> By design meaning \"I didn't feel like implemening it because I do not\n> personally care\" or \"I have some reason not to resolve symlinks\"?\n\nIMHO those symlinks would be a nice thing in some corner cases, but \npenalise the common case.  So I tend to believe the latter.  (See also \nLinus' message why he talks about his preference for the die() code path.)\n\nCiao,\nDscho\n"},{"id":"61871","messageId":"200712040742.24728.robin.rosenberg.lists@dewire.com","threadId":"11104","inReplyTo":"Pine.LNX.4.64.0712040216220.27959@racer.site","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-12-04T06:42:23Z","receivedAt":"2007-12-04T06:42:23Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 04 december 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Mon, 3 Dec 2007, Jeff King wrote:\n> \n> > On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:\n> > \n> > > code did not pass). Like Linus, this code does not resolve symlinks,\n> > > but I forgot to state that it is by design. It solves my problem and\n> > \n> > By design meaning \"I didn't feel like implemening it because I do not\n> > personally care\" or \"I have some reason not to resolve symlinks\"?\n> \n> IMHO those symlinks would be a nice thing in some corner cases, but \n> penalise the common case.  So I tend to believe the latter.  (See also \n> Linus' message why he talks about his preference for the die() code path.)\n\nActually the forme.... I don't mind it being fixed if it doesn't cost too much.\n\n-- robin\n"},{"id":"61900","messageId":"Pine.LNX.4.64.0712041149440.27959@racer.site","threadId":"11104","inReplyTo":"200712040742.24728.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-04T11:50:57Z","receivedAt":"2007-12-04T11:50:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Dec 2007, Robin Rosenberg wrote:\n\n> tisdag 04 december 2007 skrev Johannes Schindelin:\n> \n> > On Mon, 3 Dec 2007, Jeff King wrote:\n> > \n> > > On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:\n> > > \n> > > > code did not pass). Like Linus, this code does not resolve \n> > > > symlinks, but I forgot to state that it is by design. It solves my \n> > > > problem and\n> > > \n> > > By design meaning \"I didn't feel like implemening it because I do \n> > > not personally care\" or \"I have some reason not to resolve \n> > > symlinks\"?\n> > \n> > IMHO those symlinks would be a nice thing in some corner cases, but \n> > penalise the common case.  So I tend to believe the latter.  (See also \n> > Linus' message why he talks about his preference for the die() code \n> > path.)\n> \n> Actually the forme.... I don't mind it being fixed if it doesn't cost \n> too much.\n\nI do remember the hassles I went through with get_relative_cwd() until I \nbroke down and used chdir() two times (ugly).  So the latter reason is \ngood enough that you do not even have to admit to the former reason ;-)\n\nCiao,\nDscho\n"},{"id":"61922","messageId":"alpine.LFD.0.9999.0712040756370.2981@woody.linux-foundation.org","threadId":"11104","inReplyTo":"Pine.LNX.4.64.0712041149440.27959@racer.site","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-04T15:59:43Z","receivedAt":"2007-12-04T15:59:43Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 4 Dec 2007, Johannes Schindelin wrote:\n> \n> I do remember the hassles I went through with get_relative_cwd() until I \n> broke down and used chdir() two times (ugly).\n\nIt really is a pretty heavy and complex operation in UNIX in general (and \nopen to various races too), which is why I'd generally suggest avoiding it \nif you at all can.\n\nThe sad(?) part is, it's fairly trivial to do inside the Linux kernel (but \nprobably not in other operating systems - it's only because of our \nsuperior dcache that we could do it). So a special system call would be no \nproblem at all. But obviously very unportable indeed.\n\n\t\t\tLinus\n"},{"id":"61951","messageId":"20071204220840.GA3340@coredump.intra.peff.net","threadId":"11104","inReplyTo":"alpine.LFD.0.9999.0712040756370.2981@woody.linux-foundation.org","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-04T22:08:40Z","receivedAt":"2007-12-04T22:08:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 04, 2007 at 07:59:43AM -0800, Linus Torvalds wrote:\n\n> > I do remember the hassles I went through with get_relative_cwd() until I \n> > broke down and used chdir() two times (ugly).\n> \n> It really is a pretty heavy and complex operation in UNIX in general (and \n> open to various races too), which is why I'd generally suggest avoiding it \n> if you at all can.\n\nIt is more expensive, though we will be doing it once per user-supplied\npathspec, so I don't know that it will actually have an impact.\n\nI am concerned that not supporting symlinks will make this feature\nunusably annoying for some users. I used to have a home directory that\nhad a symlink in it, and I frequently ran into these sorts of path\ncomparison issues ($HOME was /home/peff, so typing ~/repo/file pointed\nthere, but /home was a symlink to /mnt/data/home, so any routines that\nnormalize the cwd used /mnt/data/home/repo, and the two never matched\nup).\n\nHrm. Looks like somebody has already helpfully implemented\nmake_absolute_path, so it would just require calling that on each\nargument. Something like this on top of Robin's patch:\n\ndiff --git a/setup.c b/setup.c\nindex 4ee8024..e76c83c 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -58,7 +58,8 @@ const char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n \tif (is_absolute_path(path))\n-\t\tpath = strip_work_tree_path(prefix, len, path);\n+\t\tpath = strip_work_tree_path(prefix, len,\n+\t\t\t\txstrdup(make_absolute_path(path)));\n \n \tfor (;;) {\n \t\tchar c;\n\n-Peff\n"},{"id":"61958","messageId":"alpine.LFD.0.9999.0712041444090.13796@woody.linux-foundation.org","threadId":"11104","inReplyTo":"20071204220840.GA3340@coredump.intra.peff.net","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-04T22:52:15Z","receivedAt":"2007-12-04T22:52:15Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 4 Dec 2007, Jeff King wrote:\n> \n> It is more expensive, though we will be doing it once per user-supplied\n> pathspec, so I don't know that it will actually have an impact.\n\nWell, I'm more worried about just bugs, actually.\n\nDoing this right is actually rather hard. For example, our current \n\"make_absolute_path()\" is simply not very good, and it's almost impossible \nto *make* it very good.\n\nWhy? It relies on being able to get the current cwd, which isn't always \neven possible on all systems. What about unreadable directories? What \nabout just so *deep* directories, that the cwd doesn't fit in the 1kB \nallocated for it? Both do happen (people use executable but non-readable \ndirectories for security sometimes). I'm also almost certain that you can \nconfuse it by renaming directories while that thing is running, etc etc.\n\nIOW, that whole thing is simply a bug waiting to happen. The fact that it \napparently *always* runs whether needed or not just seems to make it worse \n(ie if we already know our cwd, and the absolute path we have already has \nthat as a prefix, just strip it off, don't try to do anything complex, and \nleave the complex and fragile cases for the odd-ball when the simple \napproach doesn't work)\n\n\t\t\tLinus\n"},{"id":"62112","messageId":"20071206061234.GC23309@coredump.intra.peff.net","threadId":"11104","inReplyTo":"alpine.LFD.0.9999.0712041444090.13796@woody.linux-foundation.org","subject":"Re: [PATCH] Make Git accept absolute path names for files within the work tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-06T06:12:34Z","receivedAt":"2007-12-06T06:12:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 04, 2007 at 02:52:15PM -0800, Linus Torvalds wrote:\n\n> IOW, that whole thing is simply a bug waiting to happen. The fact that it \n> apparently *always* runs whether needed or not just seems to make it worse \n> (ie if we already know our cwd, and the absolute path we have already has \n> that as a prefix, just strip it off, don't try to do anything complex, and \n> leave the complex and fragile cases for the odd-ball when the simple \n> approach doesn't work)\n\nFair enough. Something like this then? It gets called only as a\nlast-ditch (though I think the 'return path' should simply be a die\n-- what is the point of getting a pathspec that isn't in the repo?).\n\n---\ndiff --git a/setup.c b/setup.c\nindex 4ee8024..fbb956e 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -5,13 +5,17 @@ static int inside_git_dir = -1;\n static int inside_work_tree = -1;\n \n static\n-const char *strip_work_tree_path(const char *prefix, int len, const char *path)\n+const char *strip_work_tree_path(const char *prefix, int len, const char *path,\n+\t\tint canonicalized)\n {\n \tconst char *work_tree = get_git_work_tree();\n \tint n = strlen(work_tree);\n \n \tif (strncmp(path, work_tree, n))\n-\t\treturn path;\n+\t\treturn canonicalized ?\n+\t\t\tpath :\n+\t\t\tstrip_work_tree_path(prefix, len,\n+\t\t\t\t\txstrdup(make_absolute_path(path)), 1);\n \n \tif (!prefix && !path[n])\n \t\treturn path + n;\n@@ -58,7 +62,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n \tif (is_absolute_path(path))\n-\t\tpath = strip_work_tree_path(prefix, len, path);\n+\t\tpath = strip_work_tree_path(prefix, len, path, 0);\n \n \tfor (;;) {\n \t\tchar c;\n"}]}