Re: Extending "extended SHA1" syntax to traverse through gitlinks?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 24, 2016, 05:36 UTC
Message-ID: <xmqq60qqu3rl.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <b2f7ff11-23b4-1065-2207-43f736c91988@gmail.com>

Jakub Narębski <jnareb@gmail.com> writes:

Show 7 quoted lines

> The point is that submodule has it's own object database.  It might
> be the same as superproject's, but you need to handle submodule objects
> being in separate submodule repository anyway.  Common repository is
> just a special case.
>
> By the way, this also means that proposed "extended extended SHA1"
> syntax would be useful to user's of submodules...

Not really.

I think that you gave a prime example why <treeish>:<path1>//<path2> is not a useful thing for submodules. When the syntax resolves to a 40-hex object name, that object name by itself is not useful.

You also need to carry an additional piece of information that lets you identify the location of the repository, in which the object name is valid, in the current user's context (i.e. somewhere in the superproject where the submodule lives). In other words, you'd need to carry <treeish>:<path1> around anyway for the object name to be useful, so there is no good reason why anybody should insist that the plumbing level resolve <treeish>:<path1>//<path2> directly to an object name in the first place.