Hi, On Tue, 18 Dec 2007, Dana How wrote: > On Dec 18, 2007 2:43 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
