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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 18, 2007 1:53 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 18 Dec 2007, Jakub Narebski wrote:
> >
> > What cwd? <path> in <tree-ish>:<path> syntax is "relative" to <tree-ish>.
> > IMHO "<tree-ish>:<path>" should be considered (and is considered) as
> > one object: current working directory doesn't matter at all there,
> > contrary to "<tree-ish> -- <pathspec>" where it is natural that <pathspec>
> > is relative to current working directory.
>
> Indeed.
>
> The <treeish>:<path> syntax *is* relative, but it's relative to the exact
> *treeish* that is given. It has nothing what-so-ever to do with the
> current working directory, since the user has explicitly given an exact
> tree object, and trying to fake that out would be actively wrong.

I think the solution is to use the cwd only when the tree-ish refers
to a commit.
If it refers explicitly to a tree (or to a tree through a tag w/o
going through a commit)
then you don't make any modification.

When it *does* refer to a commit,  then for commit:relpath you prefix
relpath with the suffix of the cwd which is an extension beyond the root
of the working tree.

At the time I thought this through submodules didn't exist.
Clearly that case needs to be thought through as well.

> That said, I can kind of understand the wish for something like this, and
> I suspect that we could make the "commit->tree" translation take the
> current path into account. In other words, maybe we should have something
> like this:
>
>         /*
>          * This sequence currently works
>          */
>         [torvalds@woody git]$ git rev-parse HEAD
>         f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768
>
>         [torvalds@woody git]$ git rev-parse HEAD^{tree}
>         051fb0c0dff4371f97f8ad9407f9f1fd335b1682
>
>         [torvalds@woody git]$ git rev-parse HEAD^{tree}:t
>         49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
>         /*
>          * .. but this would be new
>          */
>         [torvalds@woody git]$ cd t
>         [torvalds@woody t]$ git rev-parse HEAD^{tree}
>         49d8bcd7a2df5c17193b1d002c4a8489d4fa990c
>
> where the magic is *not* done by any "SHA1 path lookup" at all, but is
> simply done by the commit->tree lookup. At least at that point it would
> make logical sense (although it would probably be quite painful to
> implement).

I must be missing something.  The old patch I submitted did this.
Its defect was that it did NOT make the cwd insertion conditional
on whether the tree-ish involved a commit or not (a test which also
_seems_ doable,  but I don't think I finished it & sent it in).

Thanks,
-- 
Dana L. How  danahow@xxxxxxxxx  +1 650 804 5991 cell
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux