On Thu, Apr 30, 2015 at 12:46:02PM -0700, Junio C Hamano wrote:
> David Turner <dturner@xxxxxxxxxxxxxxxx> 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
--
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