git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Marc Branchaud <marcnarc@xiplink.com>,
	git@vger.kernel.org, Duy Nguyen <pclouds@gmail.com>,
	Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH] new-workdir: Never try to recurse into submodules on the initial checkout.
Date: Mon, 14 Jan 2019 13:58:04 -0800	[thread overview]
Message-ID: <20190114215804.GE162110@google.com> (raw)
In-Reply-To: <xmqqwon6ud7e.fsf@gitster-ct.c.googlers.com>

Hi,

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Marc Branchaud wrote:

>>> The new workdir is empty before the checkout, so attempts to recurse into
>>> a non-existent submodule directory fail.
>>>
>>> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
>>> ---
>>
>> Thanks for reporting.  Can you describe the error message when it fails
>> here?
[...]
> IOW, at the point in that script where we call "git checkout -f", if
> we changed it to "git checkout --recurse-submodules -f", what breaks
> and why?  Shouldn't it succeed instead?

I think that's a similar question to the one I asked.

But I have a good guess about what goes wrong.  It's related to the same
issue as the "git worktree" problem Marc described.

Inside the superproject's $GIT_DIR, we see

	config
	modules/
		a/
			config
		b/
			config
	...

The question is what to do with the modules/ directory when you have
multiple working directories making use of the refs and objects from
this $GIT_DIR.

In general, the most useful answer is that the additional working
directories should make use for modules/ from this $GIT_DIR as well.
After all, each submodule has its own refs and objects, and the same
motivation that pushes us to share the refs and objects from the
superproject would drive us to share them in the submodules as well.

However, if you do this in the most naive way, it will not work.  In
the config file, there is a core.worktree setting that ensures that
commands run from a submodule affect the correct working directory.
Which worktree should it point to?  All of them.

There's still an obvious "most useful" answer: each submodule should
contain its own worktrees/ directory with metadata specific to each
worktree.  This should work fine and is the future work that Marc and
I alluded to.  Let me call it (*), for later reference.

Anything done today is papering over the sad truth that that future
work (*) has not been done yet.

contrib/workdir is currently naive about all this: it does *not*
symlink across the modules/ directory, so each workdir gets its own
independent copy of all the submodules.  Which kind of defeats the
point of this kind of setup.

That said, it's better than nothing at all, which is why Marc proposes
making it not attempt to check out the submodules right away, instead
permitting the user to make the best of things.  I suppose another
thing that is missing is a warning message to ensure the user knows
that once (*) arrives, they need to be ready for it.  (Or not: this is
contrib/workdir, and there would be no need to make use of it in place
of "git worktree" once that moment arrives.)

To reiterate, this is all about papering over (*) not having been
done.

Marc, did I understand correctly?

Thanks,
Jonathan

  reply	other threads:[~2019-01-14 21:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 17:27 [PATCH] new-workdir: Never try to recurse into submodules on the initial checkout Marc Branchaud
2019-01-14 21:34 ` Jonathan Nieder
2019-01-14 21:44   ` Junio C Hamano
2019-01-14 21:58     ` Jonathan Nieder [this message]
2019-01-15 15:02       ` Marc Branchaud
2019-01-15 18:38       ` Junio C Hamano
2019-01-15 15:01   ` Marc Branchaud
2019-01-15 15:07 ` [PATCHv2] " Marc Branchaud

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190114215804.GE162110@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=marcnarc@xiplink.com \
    --cc=pclouds@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).