Re: [RFC PATCH 0/3] submodules with no working tree shall unset core.worktree

[Stefan Beller <sbeller@google.com>]

On Wed, Jun 13, 2018 at 11:00 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Beller <sbeller@google.com> 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
themselves:

    $ cd .git && find . |grep config |grep sha1co
    ./modules/sha1collisiondetection/config
    ./worktrees/git/modules/sha1collisiondetection/config

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

  .git/modules/<submodule-name>/worktrees/<worktree-name>
  .git/worktrees/<worktree-name>/modules/<submodule-name>

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

An advantage for
   .git/worktrees/<worktree-name>/modules/<submodule-name>
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
  .git/modules/<submodule-name>/worktrees/<worktree-name>
is to have any submodule related things in one place in
  .git/modules/<submodule-name>

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
  .git/modules/<submodule-name>/worktrees/<worktree-name>
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

 .git/modules/<submodule-name>/worktrees/<specific-worktree>

discover the common dir at

 .git/modules/<submodule-name>

and then proceed in listing worktrees by exploring worktrees/.
If we had put it in the other form of
   .git/worktrees/<worktree-name>/modules/<submodule-name>
we'd discover the common git dir at
  .git/modules/<submodule-name>
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.

Stefan