Re: log/show: relative pathnames do not work in rev:path

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 18 Dec 2007, Dana How wrote:

> On Dec 18, 2007 2:43 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 18 Dec 2007, Alex Riesen wrote:
> > > But the act of running "git-show <tree-ish>:<path>" does have a working
> > > directory relative to the project root.
> >
> > Not necessarily.  My primary use of "git show <tree-ish>:<path>" (yes, I
> > already use the dash-less form ;-) is in _bare_ repositories.
> >
> > And I still maintain that expecting <tree-ish>:<path> to take the current
> > relative path into account would be just like if you expected
> >
> >         C:\> cd WINDOWS
> >         C:\WINDOWS> dir D:system32
> >
> > to show you the contents of D:\WINDOWS\system32.
> >
> > Or another, less Windowsy example:
> >
> >         $ cd /usr/bin
> >         $ scp home:bash ./
> >
> > No, this does not copy home:/usr/bin/bash but home:$HOME/bash.
> 
> Both of your counterexamples use 2 disjoint directory trees:
> C: vs D:,  or trees on different machines.

Well, the first actually only uses 1 "disjoint" directory tree.  You did 
not address the concern of the bare repository.

> The cases we are talking about are all subtrees of the working tree. 
> There is a useful cwd suffix.

Not necessarily.  You can be in a subdirectory that was not even created 
in _any_ revision.  Or you can access a different branch with a different 
history.

It boils down to this: if you need relative paths _only_, you narrowed 
yourself very much in your use cases.

> Don't you think that
>   git <op> commit:./file.c
> could occasionally be more convenient than
>   git <op> commit:very/long/and/boring/path/equal/to/cwd/file.c
> ?

Actually, it depends on the <op>.  And guess what, for those operations 
that I would like to have that, it already works!  "grep", "diff", "log".

Ciao,
Dscho