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

[David Turner <dturner@twopensource.com>]

On Thu, 2015-04-30 at 10:12 +0200, Michael Haggerty wrote:
> On 04/30/2015 07:34 AM, Junio C Hamano wrote:
> > [...]
> > But stepping back a bit.
> > 
> > We have been talking about HEAD^{resolve}:fleem but how did we learn
> > that there is a path "fleem" in the tree of HEAD in the first place?
> > I would presume that the answer eventually boils down to "somebody
> > fed HEAD to 'ls-tree -r'", and then that somebody is an idiot if it
> > did not grab the mode bits to learn what kind of blob fleem is, or
> > if it did not tell the guy that wants to drive "cat-file --batch".
> 
> I think a plausible use case for this feature is to read
> `$tag^{resolve}:RelNotes`, in which case the reason we know it's there
> is "because the maintainer told us it is there".

Yes, that is approximately my use case.  Read on for details:
With a colleague, I'm building a mode for the free and open source Pants
build system that will support build-aware sparse checkouts.  Pants is a
build tool for monorepos (inspired by Google's Blaze and similar to
Facebook's Buck).  Most individual users will only be using a tiny
subset of the full repository, so it would be convenient if they only
had to check out what the plan to use.  Assume that they want to check
out only a certain target (a path, approximately) plus its transitive
dependencies, on a certain revision.  So pants first checks that
directory (at that rev) for a BUILD file.  That BUILD file might point
to other BUILD files as dependencies, so again, we must examine those,
recursively.  

In no case did we do a ls-files command, since we want to examine as
little of the repo as possible.  And even if we had done an ls-files, we
would still need to resolve all of the symlinks ourselves.

So that's the motivation here.