Re: [PATCH] git-new-workdir: support submodules

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 26.01.2015 um 06:39 schrieb Junio C Hamano:
> Craig Silverstein <csilvers@khanacademy.org> writes:
>
>> This patch, in adding submodule support, I expect would be
>> similarly useful to people even though it, also, imposes those
>> same constraints to the submodule's config files.
>
> I would expect that you would see exactly the same issue with Duy's
> multiple work tree series.  This is not limited to new-workdir.
>
> The right way to look at this is to fix what "git submodule" does;
> its use of "config" that is shared across branches is the root cause
> of the trouble.  No other part of Git keeps data that needs to be
> per-branch (or more specifically "tied to the working tree state")
> in .git/config in such a way that leaving it stale when the working
> tree state changes breaks the system.

I'm not sure what submodule config shared across branches you are
referring to here, the only two things that submodules by default
store in .git/config are the url (to mark the submodule initialized)
and the update setting (which I believe should be copied there in
the first place, but changing that in a correct and backwards
compatible would take some effort). This means you'll init (or
deinit) a submodule in all multiple worktrees at the same time, but
having the url setting in .git/config is a feature, not a bug.

And if you are talking about the core.worktree setting in
.git/modules/<submodule_name>/config, I proposed way to get rid of
that when we moved the submodule .git directory there (but that
wasn't accepted):

    http://permalink.gmane.org/gmane.comp.version-control.git/188007

Additionally I suspect submodules are just the first to suffer,
other worktree specific config (like e.g. EOL settings) affecting
all multiple worktrees at the same time when changed in a single
worktree might easily confuse other users too.

> One way to do so might be to move the bits it stores in the config
> file to somewhere else that is more closely tied to the checkout
> state and handle that similar to .git/index and .git/HEAD when it
> comes to multiple work-trees.

Yup, the idea of separating config entries into worktree and repo
specific files sounds like the solution for these problems.