# [PATCH] git-checkout: Handle relative paths containing "..". 4 messages from 2007-11-08 to 2007-11-08. Participants: David Symonds, Junio C Hamano, Johannes Schindelin. Thread: https://gitlist.dev/t/10716 ## David Symonds, 2007-11-08 02:33 Subject: [PATCH] git-checkout: Handle relative paths containing "..". Message-ID: <1194489192-20021-1-git-send-email-dsymonds@gmail.com> URL: https://gitlist.dev/e/1194489192-20021-1-git-send-email-dsymonds%40gmail.com ``` Based on gitte's idea. Signed-off-by: David Symonds --- git-checkout.sh | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/git-checkout.sh b/git-checkout.sh index 8993920..b2c50aa 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -134,9 +134,10 @@ Did you intend to checkout '$@' which can not be resolved as commit?" fi # Make sure the request is about existing paths. - git ls-files --error-unmatch -- "$@" >/dev/null || exit - git ls-files -- "$@" | - git checkout-index -f -u --stdin + git ls-files --full-name --error-unmatch -- "$@" >/dev/null || exit + git ls-files --full-name -- "$@" | + (cd "$(git-rev-parse --show-cdup)" && + git checkout-index -f -u --stdin) # Run a post-checkout hook -- the HEAD does not change so the # current HEAD is passed in for both args -- 1.5.3.5.1529.g69a1-dirty ``` ## Junio C Hamano, 2007-11-08 08:30 Subject: Re: [PATCH] git-checkout: Handle relative paths containing "..". Message-ID: <7v4pfx3zs3.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v4pfx3zs3.fsf%40gitster.siamese.dyndns.org In-Reply-To: <1194489192-20021-1-git-send-email-dsymonds@gmail.com> ``` David Symonds writes: > diff --git a/git-checkout.sh b/git-checkout.sh > index 8993920..b2c50aa 100755 > --- a/git-checkout.sh > +++ b/git-checkout.sh > @@ -134,9 +134,10 @@ Did you intend to checkout '$@' which can not be resolved as commit?" > fi > > # Make sure the request is about existing paths. > - git ls-files --error-unmatch -- "$@" >/dev/null || exit > - git ls-files -- "$@" | > - git checkout-index -f -u --stdin > + git ls-files --full-name --error-unmatch -- "$@" >/dev/null || exit > + git ls-files --full-name -- "$@" | > + (cd "$(git-rev-parse --show-cdup)" && > + git checkout-index -f -u --stdin) Have you tested this patch from the toplevel of any tree, where "git-rev-parse --show-cdup" would yield an empty string? I also wonder how this patch (with an obvious fix to address the above point) would interact with GIT_DIR and/or GIT_WORK_TREE in the environment. ``` ## David Symonds, 2007-11-08 13:10 Subject: Re: [PATCH] git-checkout: Handle relative paths containing "..". Message-ID: URL: https://gitlist.dev/e/ee77f5c20711080510i138729b9vb0b9ad485cb2db3%40mail.gmail.com In-Reply-To: <7v4pfx3zs3.fsf@gitster.siamese.dyndns.org> ``` On Nov 8, 2007 7:30 PM, Junio C Hamano wrote: > > Have you tested this patch from the toplevel of any tree, where > "git-rev-parse --show-cdup" would yield an empty string? No, I didn't. Arguably, "git-rev-parse --show-cdup" should always return a path to the top-level, which would make this kind of construction much simpler. Is there anything that relies upon it returning the empty string when you're in the top-level directory? > I also wonder how this patch (with an obvious fix to address the > above point) would interact with GIT_DIR and/or GIT_WORK_TREE in > the environment. No idea. I'm still learning my way around the git codebase, so I was hoping for some review and feedback from more experienced Gits. Dave. ``` ## Johannes Schindelin, 2007-11-08 14:25 Subject: Re: [PATCH] git-checkout: Handle relative paths containing "..". Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0711081420570.4362%40racer.site In-Reply-To: ``` Hi, On Fri, 9 Nov 2007, David Symonds wrote: > On Nov 8, 2007 7:30 PM, Junio C Hamano wrote: > > > > Have you tested this patch from the toplevel of any tree, where > > "git-rev-parse --show-cdup" would yield an empty string? > > No, I didn't. Arguably, "git-rev-parse --show-cdup" should always return > a path to the top-level, which would make this kind of construction much > simpler. As it is, we have a convenience function for this, to make it much simpler: cd_to_toplevel in git-sh-setup. > > I also wonder how this patch (with an obvious fix to address the above > > point) would interact with GIT_DIR and/or GIT_WORK_TREE in the > > environment. > > No idea. I'm still learning my way around the git codebase, so I was > hoping for some review and feedback from more experienced Gits. It _should_ work with GIT_DIR/GIT_WORK_TREE, as the full name is relative to the project root, and that's exactly where cd_to_toplevel is jumping to. And the first call to ls-files should make certain that the paths are correct, so there should be no confusion either. But yes, I have been burnt by that work tree stuff too many times, so I'd appreciate tests for that (both positive and negative ones). Ciao, Dscho ```