From: Jens Lehmann Date: Tue, 27 Jan 2015 17:35:41 GMT Subject: Re: [PATCH] git-new-workdir: support submodules Message-ID: <54C7CC6D.80906@web.de> In-Reply-To: Am 26.01.2015 um 06:39 schrieb Junio C Hamano: > Craig Silverstein 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//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.