Feature request: relative paths

Feature request: relative paths

[Eli Barzilay]

An svn feature that I used a lot is `svn cat some-file' -- and with
git I can get close to that with `git show :some-file', except that
unlike other paths, it must be an absolute path from the repository
root.  I could obviously make up a script that will do it, but that's
just buying myself some time until I find some other command where
I'll want to use it.

It looks like it would be relatively easy to do this, since when I do
specify the relative path I get an error message suggesting the full
one (provided that the relative path is simple -- no ".." etc).  So,
now that I can actually UTSL, I went there, and tried some half-assed
hacking -- I made it so "::path" uses the prefix and normalizes the
result, so, for example

  cd git/Documentation
  git show ::../Documentation/./user-manual.conf

works as expected.  Using "::" looks bad IMO, and the hack I did is
likely suffering from some problems, but overall it doesn't look too
hard.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Re: Feature request: relative paths

[Jonathan Nieder]

Eli Barzilay wrote:

> An svn feature that I used a lot is `svn cat some-file' -- and with
> git I can get close to that with `git show :some-file'

git show -- some-file

Hope that helps,
Jonathan

Re: Feature request: relative paths

[Björn Steinbrink]

On 2010.05.06 03:31:13 -0500, Jonathan Nieder wrote:
> Eli Barzilay wrote:
> 
> > An svn feature that I used a lot is `svn cat some-file' -- and with
> > git I can get close to that with `git show :some-file'
> 
> 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.

Björn

Re: Feature request: relative paths

[Jonathan Nieder]

Björn Steinbrink wrote:
> On 2010.05.06 03:31:13 -0500, Jonathan Nieder 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.

Thanks for catching the thinko.

> While ":some-file" (most likely)
> identifies a blob, so "git show :some-file" shows the contents stored in
> that blob.

I suggest reviving Dscho’s :./ syntax[1].

Cheers,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/68786/focus=68905

Re: Feature request: relative paths

[Jeff King]

On Thu, May 06, 2010 at 04:01:33AM -0500, Jonathan Nieder wrote:

> I suggest reviving Dscho’s :./ syntax[1].
> [1] http://thread.gmane.org/gmane.comp.version-control.git/68786/focus=68905

Oops, I was wrong about "there is no patch" (apparently I even submitted
a followup!).

Yes, I think that patch is a sane start, but it needs some cleanup.

-Peff

Re: Feature request: relative paths

[Jeff King]

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