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

From: Dana How <danahow@gmail.com>
Date: Dec 19, 2007, 01:52 UTC
Message-ID: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
In-Reply-To: <alpine.LFD.0.9999.0712181711100.21557@woody.linux-foundation.org>

On Dec 18, 2007 5:16 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 10 quoted lines

> On Tue, 18 Dec 2007, Dana How wrote:
> > The cases we are talking about are all subtrees of the working tree.
> > There is a useful cwd suffix.
>
> No.
>
> The cases we're talking of are *not* subtrees of the working tree.
>
> The SHA1 of a commit may well be a totally disjoint tree. Try it in the
> git repository with something like

Agreed,  but note you wrote *may*.

I'd like to move some stuff currently in a p4 repository into git. The directory structure within the repo is 13 levels deep; I didn't design it nor can I change it.

For the majority of the cases of interest to me git already accepts relative paths. However, one thing people do often in p4 (or any SCM) is look at (or compare, etc) specific revisions. Unfortunately, these are not part of branches or commits, they are just file-specific revisions (don't get me started on p4 "branches"). The equivalent in git is to use a commit name (or a tag) and then name the file. The basic commit:file syntax doesn't accept relative paths. I am not specifically hung up on the commit:./path syntax; I just want some notation that will get those 13 directories from $cwd instead of making me type them again. Yes, sometimes that might not make sense to request.

There was some mention of bash/zsh completions Unfortunately, much of our CAD environment is not configured in bash/zsh, so although I use bash for some scripting, it's not the default for command-line, and won't be used by others I need to drag along with me...

Show 13 quoted lines

> In fact, you can very well think of the commit/tree as a "drive letter".
> It really does go into another namespace entirely. It's just that often
> that namespace does bear some relationship to the currently checked out
> branch. But that's just an "often", it's not at all a given.
>
> > 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
>
> It's not about "convenience". It's about *sanity* and good design. And the
> fact is, that "commit:path" format really has nothing to do with the CWD
> in the general case.

Yes I frequently get to be one of the people here pushing for (and sometimes losing the case for) "good design". But I will never be able to successfully argue for retyping 13 directories already in the cwd because it's the "good" or "sane" thing to do.

Given that the root of the current working tree, the commit, the cwd, and the path (suffix) given on the command line are all known precisely, it does not seem dangerous to come up with an exact rule to combine them which is only triggered by some specific syntax.

This does not need to work in bare repositories.

Thanks,

-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell

(Junio removed from cc: at his request)