W dniu 24.08.2016 o 07:36, Junio C Hamano pisze:
> Jakub Narębski <jnareb@xxxxxxxxx> 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
--
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