git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

From
Stefan Beller <sbeller@google.com>
Date
Jul 22, 2016, 17:40 UTC
Message-ID
<CAGZ79kbH=ywi7sXUz5KKyRqo-Eg4RF3W9pf53rzKE-oz5-PW1Q@mail.gmail.com>
In-Reply-To
<xmqqmvl9boju.fsf@gitster.mtv.corp.google.com>
On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> From a users POV there are:
>> * non existent submodules (no gitlink recorded, no config set,
>>   no repo in place)
>> * not initialized submodules (gitlink is recorded, no config set,
>>   and an empty repo is put in the working tree as a place holder).
I meant empty directory, not empty repo.
>
> This is no different from what you later call "embedded".  The only
> difference is that embedded thing hasn't seen its initial commit.

That did not occur to me. The "not initialized" is what you'd get via

    git clone --no-recurse repo-with-submodules
whereas the "embedded" could come from
   git clone <repo with no submodules> tmp
   cd tmp && git clone <another repo, maybe unrelated>
Show 9 quoted lines
>
>> * initialized submodules (gitlink is recorded, the config
>>   submodule .<name>.url is copied from the .gitmodules file to .git/config.
>>   an empty dir in the working tree as a place holder)
>>   A user may change the configuration before the next step as the url in
>>   the .gitmodules file may be wrong and the user doesn't want to
>>   rewrite history
>
> i.e. what "submodule init" gives you.
Right.
Show 6 quoted lines
>
>> * existing submodules (gitlink is recorded, the config option is set
>>   and instead of an empty placeholder dir, we actually have a git
>>   repo there.)
>
> i.e. what "submodule update" after "submodule init" gives you.
Right.
Show 7 quoted lines
>
>> * matching submodules (the recorded git link matches
>>   the actual checked out state of the repo!, config option and repo exist)
>
> Is this any different from "existing" case for the purpose of
> discussing the interaction between a submodule (and its checkout)
> and having possibly multiple worktrees of its superproject?
I don't think so.
Show 7 quoted lines
>
> I agree that when a top-level superproject has multiple worktrees
> these multiple worktrees may want to have the same submodule in
> different states, but I'd imagine that they want to share the same
> physical repository (i.e. $GIT_DIR/modules/$name of the primary
> worktree of the superproject)---is everybody involved in the
> discussion share this assumption?
At least me agrees.
Show 13 quoted lines
>
> Assuming that everybody is on the same page, that means "do we have
> the repository for that submodule, and if so where in our local
> filesystem?" is a bit of information shared across the worktrees of
> the superproject.  And the "name" used to identify the submodule is
> also shared across these worktrees of the superproject, as it is
> meant to be a unique (within the superproject) identifier for that
> "other" project it uses, no matter where in the superproject's
> working tree (note: this is "working tree", not "worktree") it would
> be checked out, and where the upstream URL to get further updates to
> the submodule is (i.e. that URL may change over time if they relocate,
> or it may even change when the user who works on the superproject
> decides to use a different mirror).
I agree.
Show 11 quoted lines
>
> What can be different between the instantiation of the same
> submodule in these multiple worktrees, and how they should be
> recorded?
>
>  * submodule.$name.URL?  I am not sure if we want to have different
>    "upstreams" depending on the worktree of the superproject.  While
>    there is no fundamental reason to forbid it, having to maintain a
>    single local repository for a submodule would mean they would
>    need to be treated as separate "remotes" in the submodule
>    repository.

You can only have a remote if the the submodule repo exists already. I guess that can be made a requirement.

So setting up the worktrees and submodule URLs in the config and then doing the clone of said submodule is maybe not encouraged.

Show 5 quoted lines
>
>  * submodule.$name.path of course can be different depending on
>    which commit of the superproject is checked out in the worktree,
>    as the superproject may move the submodule binding site across
>    its versions.
Right.
Show 6 quoted lines
>
>  * submodule.$name.update, submodule.$name.ignore,
>    submodule.$name.branch, etc. would need to be all different among
>    worktrees of the superproject, as that is the whole point of
>    being able to work on separate branches of the superproject in
>    separate worktrees.

What do you mean by "would need". The ability to be different or rather the veto of an 'inheritance' of defaults from the repository configuration?

Show 5 quoted lines
>
> Somewhere in this discussion thread, you present the conclusion of
> your discussion with Jonathan Nieder that there needs a separate
> "should the submodule directory be populated?" bit, which currently
> is tied to submodule.$name.URL in $GIT_DIR/config.

I'll try to get the discussion back on list and whenever Jonathan starts talking off list, I'll poke him with a stick.

Show 7 quoted lines
>  I tend to agree
> that knowing where you get other people's update of that submodule
> repository should come from and wanting to have/keep a checkout of
> that submodule in the working tree of a particular worktree are two
> different things, so such a separate bit would be needed, and that
> would belong to per-worktree configuration.
>
Okay. How would you disentangle these two things?
Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 31 in “Current state of Git worktree used with submodules?”
  1. Lars SchneiderJul 19, 2016
  2. Duy NguyenJul 20, 2016
  3. 0/4 Split .git/config in multiple worktree setupNguyễn Thái Ngọc Duy, Jul 20, 2016
  4. 1/4 worktree: add per-worktree config filesNguyễn Thái Ngọc Duy, Jul 20, 2016
  5. Stefan BellerJul 26, 2016
  6. Duy NguyenJul 26, 2016
  7. 4/4 t2029: some really basic tests for submodules in multi worktreeNguyễn Thái Ngọc Duy, Jul 20, 2016
  8. 3/4 submodule: support running in multiple worktree setupNguyễn Thái Ngọc Duy, Jul 20, 2016
  9. Stefan BellerJul 20, 2016
  10. Stefan BellerJul 22, 2016
  11. Jens LehmannJul 22, 2016
  12. Stefan BellerJul 22, 2016
  13. Junio C HamanoJul 22, 2016
  14. Stefan BellerJul 22, 2016
  15. Junio C HamanoJul 25, 2016
  16. Duy NguyenJul 22, 2016
  17. Stefan BellerJul 22, 2016
  18. Duy NguyenJul 22, 2016
  19. Stefan BellerJul 25, 2016
  20. Duy NguyenJul 26, 2016
  21. Stefan BellerJul 26, 2016
  22. Jakub NarębskiJul 27, 2016
  23. Stefan BellerJul 27, 2016
  24. Duy NguyenJul 27, 2016
  25. Stefan BellerAug 3, 2016
  26. Max KirillovJul 27, 2016
  27. Jakub NarębskiJul 27, 2016
  28. Duy NguyenJul 27, 2016
  29. 2/4 submodule: update core.worktree using git-configNguyễn Thái Ngọc Duy, Jul 20, 2016
  30. Stefan BellerJul 20, 2016
  31. Duy NguyenJul 22, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.