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

From: Jeff King <peff@peff.net>
Date: Apr 30, 2015, 19:51 UTC
Message-ID: <20150430195135.GA6742@peff.net>
In-Reply-To: <xmqqegn1z9fp.fsf@gitster.dls.corp.google.com>

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

Show 19 quoted lines

> 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