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

From: Jeff King <peff@peff.net>
Date: Apr 30, 2015, 01:16 UTC
Message-ID: <20150430011612.GA7530@peff.net>
In-Reply-To: <1430355983.14907.55.camel@ubuntu>

On Wed, Apr 29, 2015 at 06:06:23PM -0700, David Turner wrote:

Show 6 quoted lines

> >   HEAD^{resolve}:foo/bar
> [...]
>
> Just to clarify: if you do git rev-parse, and the result is an
> out-of-tree symlink, you see /foo or ../foo instead of a sha?  And if
> you "git show" it it says "symlink HEAD:../foo"?

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

-Peff