list mirror (unofficial, one of many)
 help / color / Atom feed
From: Stefan Beller <>
To: Junio C Hamano <>
Cc: git <>
Subject: Re: [RFC PATCH 0/3] submodules with no working tree shall unset core.worktree
Date: Wed, 13 Jun 2018 11:52:17 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jun 13, 2018 at 11:00 AM Junio C Hamano <> wrote:
> Stefan Beller <> writes:
> > The first patch teaches checkout/reset (with --recurse-submodules) to unset
> > the core.worktree config when the new state of the superprojects working tree
> > doesn't contain the submodules working tree.
> Are there two cases of "doesn't contain working tree of a submodule"?
> The superproject's commit may not have a gitlink to a specific
> submodule in its tree (i.e. there is no way to even "submodule init"
> with such a commit in the superproject's history).

... for example git.git before 2.13 did not have a gitlink for its
sha1collision submodule ...

>   Or there may be
> a gitlink but the user chose not to check it out in the working
> tree.

This is when the submodule is not active or de-initialized or not initialized
to begin with. However there is an empty directory as a place holder.
As long as the empty place holder is there, we do not run into trouble.

> Do they need to be treated differently, or can they be treated the
> same way?

I would think they are the same, as both cases do not have a working tree
for the submodule.

> Also, is the "submodule" feature supposed to play well with multiple
> worktree feature?

It is a long term goal to get this working.

>  Let's imagine that you have two worktrees for a
> single superproject, and the branches of the superproject these two
> worktrees check out are different ones (which is the more sensible
> set-up than checking out the same branch twice).

(git-worktree even prevents you to checkout the same branch),
sounds all very sensible up to here.

> Further imagine
> that the superproject started using a single submodule sometime in
> the past and keeps using it throughout its life since then.
>  1. if both of these two branches have the submodule, and two
>     worktrees both are interested in having the submodule checked
>     out via "submodule init/update", where does core.worktree point
>     at?  Do we have two copies of the variable?

Currently in the real world (aka in origin/master), the submodules are
completely duplicated, and do not know about the worktree feature

    $ cd .git && find . |grep config |grep sha1co

(Yes I do have a worktree called "git".)

So for the sake of this patch series this should be okay, as there
is only ever one working tree for a submodule currently.

The current state of affairs is really bad as the submodule is
there twice with all objects and the rest.

>  2. what if one branch predates the use of the submodule in the
>     superproject while the other branch is newer and uses the
>     submodule?  Where does core.worktree point at?

As we have two copies of the repository, one of them points at the
correct place, and the other would be unset.


In an ideal world we would want the submodules to use the worktree
feature along-side the superproject, e.g. if the superproject has the
two worktrees as above, the submodule would also get these.

However I have not thought about this future too deeply, as there
are a couple bumps along the road:

Supposedly the submodules main (common) git dir would stay in the
common git dir of the superproject at /modules/<name>.
However where would we put the submodules non-main worktree
git dirs? There are two places, as seen from the superprojects:


As worktrees can be removed pretty easily ("git worktree prune"),
I would not put the main parts of a submodule into a worktree part
of the superproject (The user could be in a non-main worktree
when they first ask for the submodule -- we have to make sure
the main git dir goes into the superprojects main git dir under

An advantage for
would be that the worktree of the submodule is coupled to the
worktree of the superproject, i.e. if the user wipes the superprojects
worktree, the submodules accompanying worktree is gone automatically.

An advantage for
is to have any submodule related things in one place in

Cleanup of the worktrees would be a bit harder as we'd have to
remember to prune the worktrees for all submodules as well
when the superproject removes one of its worktrees.

It is relatively rare to delete the submodule git directory compared to
removing a worktree, such that
sounds a bit more promising to me.

However the worktree command needs to figure out the worktrees:
    /path/to/super/worktree/submodule $ git worktree list

This would look at its git dir, which is


discover the common dir at


and then proceed in listing worktrees by exploring worktrees/.
If we had put it in the other form of
we'd discover the common git dir at
and list it from there.

However currently we use the existence of directories (both for
submodules as well as worktrees) to infer some knowledge about
the existence of submodules and worktrees, so we cannot just declare
one version or the other to be the future, but we'd have to add some
form of linking, I would think.


  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12 23:58 Stefan Beller
2018-06-12 23:58 ` [PATCH 1/3] submodule: unset core.worktree if no working tree is present Stefan Beller
2018-06-12 23:58 ` [PATCH 2/3] submodule: ensure core.worktree is set after update Stefan Beller
2018-06-16 20:26   ` SZEDER Gábor
2018-06-12 23:58 ` [PATCH 3/3] submodule deinit: unset core.worktree Stefan Beller
2018-06-13 18:00 ` [RFC PATCH 0/3] submodules with no working tree shall " Junio C Hamano
2018-06-13 18:52   ` Stefan Beller [this message]
2018-06-19  0:06 ` [PATCH " Stefan Beller
2018-06-19  0:06   ` [PATCH 1/3] submodule: unset core.worktree if no working tree is present Stefan Beller
2018-06-19  0:06   ` [PATCH 2/3] submodule: ensure core.worktree is set after update Stefan Beller
2018-06-19  0:06   ` [PATCH 3/3] submodule deinit: unset core.worktree Stefan Beller

Reply instructions:

You may reply publically 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 \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox