list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <>
To: "Philippe Blain" <>,
	"Вадим Цветков" <>,
Subject: Re: Git Submodules ref setting
Date: Fri, 13 May 2022 09:46:17 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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):
> - gitsubmodules(7):
> - gitmodules(5):
> I hope that helps,
> Philippe.
> [1]


  reply	other threads:[~2022-05-13  8:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 20:01 Вадим Цветков
2022-05-12 21:18 ` Philip Oakley
2022-05-12 22:42 ` Philippe Blain
2022-05-13  8:46   ` Philip Oakley [this message]
2022-05-13 15:22   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: Git Submodules ref setting' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).