Re: RFC: git cat-file --follow-symlinks?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 30, 2015, 01:31 UTC
Message-ID: <xmqq7fsu4d1x.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150430011612.GA7530@peff.net>

Jeff King <peff@peff.net> writes:

Show 37 quoted lines

> I had imagined we would stop resolution and you would just get the last
> object peeled object. Combined with teaching cat-file to show more
> object context, doing:
>
>   echo content >dest ;# actual blob
>   ln -s dest link    ;# link to blob
>   ln -s broken foo   ;# broken link
>   ln -s out ../foo   ;# out-of-tree link
>   git add . && git commit -m foo
>   for i in link broken out; do
> 	echo HEAD^{resolve}:$i
>   done |
>   git cat-file --batch="%(intreemode) %(size)"
>
> would yield:
>
>  (1)   100644 8
>        content
>  (2)   040000 3
>        foo
>  (3)   040000 6
>        ../foo
>
> where the left-margin numbers are for reference:
>
>   1. We dereference a real symlink, and pretend like we actually asked
>      for its referent.
>
>   2. For a broken link, we can't dereference, so we return the link
>      itself. You can tell by the mode, and the content tells you what
>      would have been dereferenced.
>
>   3. Ditto for out-of-tree. Note that this would be the _raw_ symlink
>      contents, not any kind of simplification (so if you asked for
>      "foo/bar/baz" and it was "../../../../out", you would the full path
>      with all those dots, not a simplified "../out", which I think is
>      what you were trying to show in earlier examples).

s/040000/160000/ I would think (if you really meant to expose a tree, write it as 40000 instead, so that people will not get a wrong impression and reimplement a broken tree object encoding some popular Git hosting site broke their customer projects with ;-).

I am not sure $treeish^{resolve} is a great syntax, but I like the concept and agree that it is a lot more sensible to handle this at the level of sha1_name.c layer than an ad-hoc solution in the cat-file layer.