From: Jeff King <peff@peff.net>
Date: Thu, 06 May 2010 09:04:19 GMT
Subject: Re: Feature request: relative paths
Message-ID: <20100506090419.GB31873@coredump.intra.peff.net>
In-Reply-To: <20100506084607.GA9921@atjola.homenet>

On Thu, May 06, 2010 at 10:46:07AM +0200, Björn Steinbrink wrote:

> > git show -- some-file
> 
> That's the same as "git show HEAD -- some-file" though, which shows a
> commit with path-limited diff output. While ":some-file" (most likely)
> identifies a blob, so "git show :some-file" shows the contents stored in
> that blob.

Yep. What Eli actually wants is to allow relative path specifiers in
tree-selectors. So you could do:

  git show :./some-file

or even

  git show HEAD~20:./some-file

and the "./" bit would magically expand into the current prefix within
the working tree.

This has come up several times on the list. It is a little bit of a
layering violation, because "treeish:path" may or may not bear any
resemblence to your current working tree. And the parsing of that syntax
happens in a fairly deep, library-ish place which doesn't know anything
about the working tree. However, in practice, I think it would be
extremely useful (because your working tree _does_ tend to be related to
the tree-ishs that you look at, especially if that tree-ish is HEAD).

I think in the past there was some vague negative sentiment around the
issues I described above. I don't think an actual patch was ever
produced, but I might be wrong. I suspect the only way to move the
discussion forward would be to actually show a patch.

-Peff