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

Re: [PATCH 1/2] store submodule in common dir

From
Duy Nguyen <pclouds@gmail.com>
Date
Aug 15, 2018, 15:20 UTC
Message-ID
<CACsJy8DH+c0tHS9VpirdE97G3+roWhvXfb-jcjW7n-5nuZo3=A@mail.gmail.com>
In-Reply-To
<xmqqk1osy1qo.fsf@gitster-ct.c.googlers.com>
On Wed, Aug 15, 2018 at 1:20 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> Theoretically we should be able to make modules/kernel%2fv2.[24]
> additional "worktree"s of modules/kernel%2fv2.6, but given that
> these are all "bare" repositories without an attached working tree,
> I am not sure how that would supposed to work.  Thinking about
> having multiple worktrees on a single bare repository makes me head
> spin and ache X-<;-)

I could only read the mail subject this morning and thought a bit about it on the train, and came to the same conclusion that "git worktree" is the way to go.

The bareness should not affect this at all. If you meant core.bare, it can only affect the main repo. But what I'm thinking is repos with only linked worktrees and no main one. So when you "submodule update" a repo, you "clone -n", then "git worktree add" to put a worktree in place. The repo is strictly speaking not bare, it just does not have a main worktree.

The main HEAD should be detached so that it does not block any worktree from checking out branches. If we could get away without the main HEAD, that would be great, but HEAD is part of the repo signature so it has to stay (and we may end up keeping more objects for this HEAD even after every other heads don't need the same objects anymore).

This also solves the problem with mupltiple worktrees on a repo with submodules, where we have the same problems (if I add a new worktree of the superproject, where do the new submodules go?). In this case ideally all worktrees should have separate ref namespaces to maintain the "separate repo" view that we currently have, but I guess we can live with sharing refs for a while.

And simply sharing $GIT_DIR/modules won't work. For starter, it breaks existing setups. What I've wanted to do is adding a shared "common" directory. Then you could have "common/modules" (among other future common stuff), which is shared across all worktrees, but you don't have to add extra share rules since it's already covered by the "common" rule.

-- 
Duy
Previous: Joakim TjernlundNext: Stefan Beller
Message 9 of 11 in “git submodule: 3 modules same git repo?”
  1. Joakim TjernlundAug 14, 2018
  2. 1/2 store submodule in common dirStefan Beller, Aug 14, 2018
  3. Junio C HamanoAug 14, 2018
  4. Junio C HamanoAug 14, 2018
  5. Stefan BellerAug 14, 2018
  6. Jonathan NiederAug 15, 2018
  7. Joakim TjernlundAug 15, 2018
  8. Joakim TjernlundAug 15, 2018
  9. Duy NguyenAug 15, 2018
  10. Stefan BellerAug 14, 2018
  11. Jonathan NiederAug 14, 2018

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.