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

[Jeff King <peff@peff.net>]

On Thu, Apr 30, 2015 at 12:46:02PM -0700, Junio C Hamano wrote:

> David Turner <dturner@twopensource.com> writes:
> 
> > The weirdest case is log.  If I say git log HEAD^{resolve} --
> > foo/bar/baz,...
> 
> That invocation does not make any sense to me, at least within the
> context of what has been discussed for ^{resolve}, which is an
> instruction to the "name to object name" mapping layer to notice
> symbolic links while it traverses the tree containment relationships
> starting from the root of the tree to arrive at a single object
> name.
> 
>     git rev-parse HEAD^{resolve}:path/that/might/involve/symlink/some/where
>     git cat-file HEAD^{resolve}:path/that/might/involve/symlink/some/where
>     git grep -e pattern HEAD^{resolve}:path/that/might/involve/symlink/some/where
> 
> would, though.  In other words, ^{resolve} that is not followed by a
> colon and path is something entirely different from what we have
> been discussing.

Yeah, I agree that HEAD^{resolve} without a colon does not make any
sense. In fact, I wanted to originally suggest a syntax that replaced
the colon with something else, to make it clear that it the modifier is
really about the colon. But I could not think of a character that was
readable and would not have backward-compatibility issues.

I guess you could spell it:

  HEAD^{resolve:foo/bar/baz}

but that opens up parsing questions for the filename. Would we allow "}"
in the filename? Or require that the "}" balance, which means
speculative parsing if there is more content after the trailing "}"
(e.g., you could in theory resolve to a tree and then stick a ":" with
more path after that. Yech).

-Peff