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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.