On Wed, Apr 29, 2015 at 06:06:23PM -0700, David Turner wrote:
> > 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
--
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