From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Nguyễn Thái Ngọc" <pclouds@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>,
"Max Kirillov" <max@max630.net>,
"Michael J Gruber" <git@drmicha.warpmail.net>,
"Jens Lehmann" <Jens.Lehmann@web.de>,
"Lars Schneider" <larsxschneider@gmail.com>,
"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup
Date: Fri, 22 Jul 2016 10:40:44 -0700 [thread overview]
Message-ID: <CAGZ79kbH=ywi7sXUz5KKyRqo-Eg4RF3W9pf53rzKE-oz5-PW1Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqmvl9boju.fsf@gitster.mtv.corp.google.com>
On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> From a users POV there are:
>> * non existent submodules (no gitlink recorded, no config set,
>> no repo in place)
>> * not initialized submodules (gitlink is recorded, no config set,
>> and an empty repo is put in the working tree as a place holder).
I meant empty directory, not empty repo.
>
> This is no different from what you later call "embedded". The only
> difference is that embedded thing hasn't seen its initial commit.
That did not occur to me.
The "not initialized" is what you'd get via
git clone --no-recurse repo-with-submodules
whereas the "embedded" could come from
git clone <repo with no submodules> tmp
cd tmp && git clone <another repo, maybe unrelated>
>
>> * initialized submodules (gitlink is recorded, the config
>> submodule .<name>.url is copied from the .gitmodules file to .git/config.
>> an empty dir in the working tree as a place holder)
>> A user may change the configuration before the next step as the url in
>> the .gitmodules file may be wrong and the user doesn't want to
>> rewrite history
>
> i.e. what "submodule init" gives you.
Right.
>
>> * existing submodules (gitlink is recorded, the config option is set
>> and instead of an empty placeholder dir, we actually have a git
>> repo there.)
>
> i.e. what "submodule update" after "submodule init" gives you.
Right.
>
>> * matching submodules (the recorded git link matches
>> the actual checked out state of the repo!, config option and repo exist)
>
> Is this any different from "existing" case for the purpose of
> discussing the interaction between a submodule (and its checkout)
> and having possibly multiple worktrees of its superproject?
I don't think so.
>
> I agree that when a top-level superproject has multiple worktrees
> these multiple worktrees may want to have the same submodule in
> different states, but I'd imagine that they want to share the same
> physical repository (i.e. $GIT_DIR/modules/$name of the primary
> worktree of the superproject)---is everybody involved in the
> discussion share this assumption?
At least me agrees.
>
> Assuming that everybody is on the same page, that means "do we have
> the repository for that submodule, and if so where in our local
> filesystem?" is a bit of information shared across the worktrees of
> the superproject. And the "name" used to identify the submodule is
> also shared across these worktrees of the superproject, as it is
> meant to be a unique (within the superproject) identifier for that
> "other" project it uses, no matter where in the superproject's
> working tree (note: this is "working tree", not "worktree") it would
> be checked out, and where the upstream URL to get further updates to
> the submodule is (i.e. that URL may change over time if they relocate,
> or it may even change when the user who works on the superproject
> decides to use a different mirror).
I agree.
>
> What can be different between the instantiation of the same
> submodule in these multiple worktrees, and how they should be
> recorded?
>
> * submodule.$name.URL? I am not sure if we want to have different
> "upstreams" depending on the worktree of the superproject. While
> there is no fundamental reason to forbid it, having to maintain a
> single local repository for a submodule would mean they would
> need to be treated as separate "remotes" in the submodule
> repository.
You can only have a remote if the the submodule repo exists already.
I guess that can be made a requirement.
So setting up the worktrees and submodule URLs in the config and
then doing the clone of said submodule is maybe not encouraged.
>
> * submodule.$name.path of course can be different depending on
> which commit of the superproject is checked out in the worktree,
> as the superproject may move the submodule binding site across
> its versions.
Right.
>
> * submodule.$name.update, submodule.$name.ignore,
> submodule.$name.branch, etc. would need to be all different among
> worktrees of the superproject, as that is the whole point of
> being able to work on separate branches of the superproject in
> separate worktrees.
What do you mean by "would need". The ability to be different or rather
the veto of an 'inheritance' of defaults from the repository configuration?
>
> Somewhere in this discussion thread, you present the conclusion of
> your discussion with Jonathan Nieder that there needs a separate
> "should the submodule directory be populated?" bit, which currently
> is tied to submodule.$name.URL in $GIT_DIR/config.
I'll try to get the discussion back on list and whenever Jonathan starts talking
off list, I'll poke him with a stick.
> I tend to agree
> that knowing where you get other people's update of that submodule
> repository should come from and wanting to have/keep a checkout of
> that submodule in the working tree of a particular worktree are two
> different things, so such a separate bit would be needed, and that
> would belong to per-worktree configuration.
>
Okay. How would you disentangle these two things?
next prev parent reply other threads:[~2016-07-22 17:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 20:59 Current state of Git worktree used with submodules? Lars Schneider
2016-07-20 4:14 ` Duy Nguyen
2016-07-20 17:24 ` [PATCH v4 0/4] Split .git/config in multiple worktree setup Nguyễn Thái Ngọc Duy
2016-07-20 17:24 ` [PATCH v4 1/4] worktree: add per-worktree config files Nguyễn Thái Ngọc Duy
2016-07-26 0:59 ` Stefan Beller
2016-07-26 15:04 ` Duy Nguyen
2016-07-20 17:24 ` [PATCH v4 2/4] submodule: update core.worktree using git-config Nguyễn Thái Ngọc Duy
2016-07-20 22:04 ` Stefan Beller
2016-07-22 17:15 ` Duy Nguyen
2016-07-20 17:24 ` [PATCH v4 3/4] submodule: support running in multiple worktree setup Nguyễn Thái Ngọc Duy
2016-07-20 23:22 ` Stefan Beller
2016-07-22 0:37 ` Stefan Beller
2016-07-22 7:32 ` Jens Lehmann
2016-07-22 16:07 ` Stefan Beller
2016-07-22 16:55 ` Junio C Hamano
2016-07-22 17:40 ` Stefan Beller [this message]
2016-07-25 15:46 ` Junio C Hamano
2016-07-22 17:09 ` Duy Nguyen
2016-07-22 17:25 ` Stefan Beller
2016-07-22 17:42 ` Duy Nguyen
2016-07-25 23:25 ` Stefan Beller
2016-07-26 17:20 ` Duy Nguyen
2016-07-26 18:15 ` Stefan Beller
2016-07-27 14:37 ` Jakub Narębski
2016-07-27 16:53 ` Stefan Beller
2016-07-27 15:40 ` Duy Nguyen
2016-08-03 21:47 ` Stefan Beller
2016-07-27 4:10 ` Max Kirillov
2016-07-27 14:40 ` Jakub Narębski
2016-07-27 14:49 ` Duy Nguyen
2016-07-20 17:24 ` [PATCH v4 4/4] t2029: some really basic tests for submodules in multi worktree Nguyễn Thái Ngọc Duy
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='CAGZ79kbH=ywi7sXUz5KKyRqo-Eg4RF3W9pf53rzKE-oz5-PW1Q@mail.gmail.com' \
--to=sbeller@google.com \
--cc=Jens.Lehmann@web.de \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=larsxschneider@gmail.com \
--cc=max@max630.net \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.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).