threads / discuss / 23714

Feature request: relative paths

Subject: Feature request: relative paths

## tl;dr

6 messages between May 6, 2010 and May 6, 2010.

replies: 5people: 4as markdown or json

Eli Barzilay· May 6, 2010, 06:01 UTC · lore

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!

Jonathan Nieder· May 6, 2010, 08:31 UTC · re: Eli Barzilay · lore

Re: Feature request: relative paths

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

Björn Steinbrink· May 6, 2010, 08:46 UTC · re: Jonathan Nieder · lore

Re: Feature request: relative paths

On 2010.05.06 03:31:13 -0500, Jonathan Nieder wrote:

Show 6 quoted lines

> 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

Jonathan Nieder· May 6, 2010, 09:01 UTC · re: Björn Steinbrink · lore

Re: Feature request: relative paths

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

Jeff King· May 6, 2010, 09:09 UTC · re: Jonathan Nieder · lore

Re: Feature request: relative paths

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

Jeff King· May 6, 2010, 09:04 UTC · re: Björn Steinbrink · lore

Re: Feature request: relative paths

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