W dniu 24.08.2016 o 16:20, Josh Triplett pisze:
> On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote:
[...]
>> 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.
>
> Depends on which cases you want to handle. In the most general case,
> you'd need to find and process the applicable .gitmodules file, which
> would only work if you started from the top-level tree, not a random
> treeish. On the other hand, in the most general case, you don't
> necessarily even have the module you need, because .git/modules only
> contains the modules the *current* version needed, not every past
> version.
There is an additional problem, namely that directory with submodule
can be renamed.
I don't know if there is an existing API, but assuming modern
git-submodule (with repository in .git/modules) you would have to
do the following steps for <revision>:<path/to/submodule>//<path>:
* look up <revision>:.gitmodules for module which 'path'
is <path/to/submodule>; let's say it is named <submodule>
* check if <revision>:<path/to/submodule> commit object
is present in .git/modules/<submodule>
* look up this object
In the case of legacy submodule setup, with submodule repository
in the supermodule working directory, you would need:
* look up <revision>:.gitmodules for module which 'path'
is <path/to/submodule>; let's say it is named <submodule>
* look up current .gitmodules for current path of submodule
named <submodule>; let's say it is <new/path/submodule>
* check of <revision>:</path/to/submodule> commit object
is present in :(top)<new/path/submodule>/.git repository
* look up this object
You could also check if the submodule repository (as stored
in config) is a path, and use it if it is... but that might
be going to far.
BTW. all that reminds me that gitweb should handle submodules
better.
> As an alternate approach (pun intended): treat every module in
> .git/modules as an alternate and just look up the object by hash.
This could be a good fallback, to search through all submodules.
> Or, teach git-submodule to store all the objects for submodules in the
> supermodule's .git/objects (and teach git's reachability algorithm to
> respect refs in .git/modules, or store their refs in
> .git/refs/submodules/ or in a namespace).
And fallback to this fallback could be searching through supermodule
object repository.
Storing all objects in single repository is counter to the design
decision of submodules (though I don't remember what it was), but
it might be done. Still, Git needs to be able to deal with legacy
situations anyway.
>> 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?
>
> This wasn't an abstract/theoretical completeness issue. I specifically
> wanted this syntax for practical use with actual trees containing
> gitlinks, motivated by having a tool that creates and uses such
> gitlinks. :)
Could you explain what you need in more detail? Is it a fragment
of history of submodule, a contents of a file at given point of
superproject history, diff between file-in-submodule and something
else, or what?
>> 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.
>
> Right. I primarily care about those first two cases, especially the
> first one: given a commit containing a gitlink, how can I easily dig
> into the linked commit?
All right.
Though you can cobble it with plumbing... just saying.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
