Re: Feature request: relative paths

From: Jeff King <peff@peff.net>
Date: May 6, 2010, 09:04 UTC
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:

Show 6 quoted lines

> > 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