Jeff King <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
