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

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).  Or there may be
a gitlink but the user chose not to check it out in the working

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

Also, is the "submodule" feature supposed to play well with multiple
worktree feature?  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).  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?

 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?


> The last patch is teaching "git submodule deinit" to unset the core.worktree
> setting as well. It turned out this one is tricky, as for that we also
> have to set it in the counter part, such as "submodule update".
> Thanks,
> Stefan
> Stefan Beller (3):
>   submodule: unset core.worktree if no working tree is present
>   submodule: ensure core.worktree is set after update
>   submodule deinit: unset core.worktree
>  builtin/submodule--helper.c | 26 ++++++++++++++++++++++++++
>            |  5 +++++
>  submodule.c                 | 14 ++++++++++++++
>  submodule.h                 |  2 ++
>  t/   |  5 +++--
>  t/  |  5 +++++
>  6 files changed, 55 insertions(+), 2 deletions(-)

  parent reply index

Thread overview: 7+ 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 ` Junio C Hamano [this message]
2018-06-13 18:52   ` [RFC PATCH 0/3] submodules with no working tree shall " 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 \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (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:
       or Tor2web:

AGPL code for this site: git clone public-inbox