On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html