Am 26.01.2015 um 06:39 schrieb Junio C Hamano:
Craig Silverstein <csilvers@xxxxxxxxxxxxxxx> 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.
--
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