Re: Git Submodules ref setting

[Philip Oakley <philipoakley@iee.email>]

On 12/05/2022 23:42, Philippe Blain wrote:
> Hi,
>
> Le 2022-05-12 à 16:01, Вадим Цветков a écrit :
>> Hello,
>>
>> I've started a small project which involves several git repositories, which depends on each other.
>> For dealing with these repos I wanted to use git submodules as a simple package manager.
>> However, it seems impossible to lock a submodule to particular ref, only to a branch.
> Submodules are recorded in the superproject *at a specific commit*.
> That's the data model. There is no other options.
>
> There is a 'branch' setting that you can put in '.gitmodules'.
> This *only* affects the command 'git submodule update --remote', nothing else.
>
> If you mean that you would like to have a non-branch ref recorded in '.gitmodules'
> i.e. something like refs/other-refs/example instead of 'some-branch' that corresponds
> to 'refs/heads/some-branch', then no this is not possible either.
>
>> I would like to ask if this is deliberate design choice?
> Yes, it was a deliberate design choice to have a deterministic state
> of a repository using submodules upon 'git clone'. Recording a submodule
> at a specific branch instead of at a specific commit would make this design
> choice impossible to achieve.
>
>> And if it's not, may I contribute this feature?
>>
> It depends on what you mean by 'lock submodule to a specific ref'.
>
> I encourage you to read the "Git Submodules" chapter of the Pro Git book [1]
> for an in-depth overview of how submodules work. And after that, for reference
> the Git documentation:

I didn't find the man page, or the scm chapter that great in explaining 
the overall way that sub-modules are conceived and organised.

There is an implicit assumption in the man pages that folks, in general, 
already know the background and concepts, and are just looking for the 
particular command option details. I.e that it is a reference manual. 
There has been a lot of work done over the years on sub-modules but, to 
me, the concentration has been on _implementation_ (which is obviously 
important), rather than _explanation_ of how sub-modules work and the 
newer capabilities mesh into the existing ones.

As seen here, the existing usage as a place holder for libraries at 
exact versions has been 'lost' in the flurry of newer capabilities. It 
maybe something to add to the wider UX discussions [A].
>
> - git-submodule(1): https://git-scm.com/docs/git-submodule
> - gitsubmodules(7): https://git-scm.com/docs/gitsubmodules
> - gitmodules(5): https://git-scm.com/docs/gitmodules
>
> I hope that helps,
>
> Philippe.
>
> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
Philip

[A] 
https://lore.kernel.org/git/CA+Yb-VSaeKy-g_ywkZzQuEX=k3EXM+Ky-rHOb2az0SHGVbdaVw@mail.gmail.com/