git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: "Вадим Цветков" <vadim.tsvetkov80@gmail.com>,
	git@vger.kernel.org, "Philip Oakley" <philipoakley@iee.email>
Subject: Re: Git Submodules ref setting
Date: Fri, 13 May 2022 08:22:56 -0700	[thread overview]
Message-ID: <xmqqwnepbgof.fsf@gitster.g> (raw)
In-Reply-To: <88fa7138-cb3f-ab88-525c-198396b0a262@gmail.com> (Philippe Blain's message of "Thu, 12 May 2022 18:42:09 -0400")

Philippe Blain <levraiphilippeblain@gmail.com> writes:

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

The above sentences are all correct, but it answers a slightly
different question, I think.

I suspect that Vadim wanted to see if it is desirable to point at a
non-branch ref with "submodule.<name>.branch" entry (or invent a new
"submodule.<name>.ref" entry) in the ".gitmodules" file.

While the answer to that question is "probably not", to understand
why, your answer helps ;-).

The "submodule.<name>.branch" entry hints the name of the branch to
be used in the named submodule while working on submodule changes
meant to go with the change that will be made to the superproject.

It is expected that the workflow goes like this:

 * A contributor checks out branch X of the superproject, which
   binds another project whose name is N as its submodule at path P.
   In the tree of the commit at the tip of branch X in the
   superproject, a concrete commit C in the submodule is recorded
   at that path.

 * The .gitmodules file found in that superproject checkout may
   record submodule.N.branch with value Y.  The commit C should be
   checked out in the submodule.

 * The contributor works on something that involves both the
   superproject and the submodule.  Perhaps the new feature in the
   superproject requires an enhanced version of the submodule, so
   there is an dependency.  New commits are added on top of C in the
   submodule, and branch Y is advanced.  The commit at the tip of
   that branch is recorded in the superproject's tree, and together
   with the changes in the superproject that use the modified
   submodule advance the branch X of the superproject.

 * The contributor shares the work with other participants by
   pushing branch X of the superproject and branch Y of the
   submodule.  There may be other branches that may be pushed out
   "while at it", but at least these two need to be pushed out.

For this workflow to work, it is necessary, as you said, that an
exact commit is recorded in the tree of the superproject.  We can
guarantee a correct build of the superproject at commit at the
updated tip of branch X, because we know which submodule commit
needs to go with it.

But it is not sufficient.  The history in the submodule needs to be
manageable---the contributors who cloned the superproject and the
submodule need to check out a commit to work on and extend their
histories, and while it is possible to work always on detached HEAD,
at the place where contributors meet with their work, i.e. the
repository their changes were pushed in the last step in the above
sequence, there needs _some_ ref.  It is possible to use a
non-branch ref for that, but because the contributors have to check
that ref out after cloning and fetching the submodule, it makes
little sense not to require that ref to be a proper branch that can
be checked out (instead of merely giving a starting point of an
unnamed branch, aka detached HEAD).

And that is why "remote.<name>.branch" is there and it is not
"remote.<name>.ref".







      parent reply	other threads:[~2022-05-13 15:23 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
2022-05-13 15:22   ` Junio C Hamano [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqwnepbgof.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=levraiphilippeblain@gmail.com \
    --cc=philipoakley@iee.email \
    --cc=vadim.tsvetkov80@gmail.com \
    --subject='Re: Git Submodules ref setting' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

	https://80x24.org/mirrors/git.git

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