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

From: Stefan Beller <sbeller@google.com>
Date: Aug 24, 2016, 16:26 UTC
Message-ID: <CAGZ79kbz2WfbJ=uEV3irg8DREaEhJJzEX0_m9FGWiik8e9=w=g@mail.gmail.com>
In-Reply-To: <20160824142024.xnaehfo2spw26apj@x>

On Wed, Aug 24, 2016 at 7:20 AM, Josh Triplett <josh@joshtriplett.org> wrote:

Show 7 quoted lines

> 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.

The code in submodule-config.{c,h} allows exactly that:

    submodule_from_path(commit_sha1, path)

returns information about the submodule recorded in a .gitmodules file of a specific revision of the superproject.

Ideally the .git/modules contains all the modules that existed, ever. Well "ideally" is the wrong word, but it is at least possible as the submodules git dir is kept even when you remove the outdated submodules working dir. (That's why the git dir is in the superprojects git dir in the first place).

But as you say, it is possible of not having the submodule available.

Show 7 quoted lines

>
> As an alternate approach (pun intended): treat every module in
> .git/modules as an alternate and just look up the object by hash.  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).

This is a sensible thing to do no matter the outcome of this discussion.

Show 12 quoted lines

>>  * 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?

What do you exactly need? (What is digging here?)

See for example the series, that Jake Keller currently tries to land:
    "submodule inline diff format"
https://public-inbox.org/git/20160822234344.22797-1-jacob.e.keller@intel.com

That would enhance all the log/diff/show things.

Reading the original message, do you want to create patches in the submodule from the superproject?

Thanks, Stefan