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

From: Jakub Narębski <jnareb@gmail.com>
Date: Aug 24, 2016, 13:16 UTC
Message-ID: <b264e17a-12ff-69ca-f130-78d2635a0f85@gmail.com>
In-Reply-To: <xmqq60qqu3rl.fsf@gitster.mtv.corp.google.com>

W dniu 24.08.2016 o 07:36, Junio C Hamano pisze:

Show 24 quoted lines

> Jakub Narębski <jnareb@gmail.com> writes:
> 
>> 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.

Not really.

The above means only that the support for new syntax would be not as easy as adding it to 'git rev-parse' (and it's built-in equivalent), except for the case where submodule uses the same object database as supermodule.

So it wouldn't be as easy (on conceptual level) as adding support for ':/<text>' or '<commit>^{/<text>}'. It would be at least as hard, if not harder, as adding support for '@{-1}' and its '-' shortcut.

Josh, what was the reason behind proposing this feature? Was it conceived as adding completeness to gitrevisions syntax, a low-hanging fruit? It isn't (the latter). Or was it some problem with submodule handling that you would want to use this syntax for?

As for usefulness: this fills the hole in accessing submodules, one that could be handled by combining plumbing-level commands. Namely, there are 5 states of submodule (as I understand it)

 * recorded in ref / commit in supermodule
 * recorded in the index in supermodule
 - recorded in ref / commit in submodule
 - recorded in the index in submodule
 - state of worktree in submodule

The last three can be easyly acessed by cd-ing to submodule. The first two are not easy to get, AFAIUC.

-- 
Jakub Narębski