From: Jens Lehmann Date: Sat, 06 Dec 2014 12:44:37 GMT Subject: Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules Message-ID: <5482FA35.40600@web.de> In-Reply-To: Am 05.12.2014 um 02:33 schrieb Duy Nguyen: > On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann wrote: >> Wow, so the .git/config is shared between all worktrees? I >> suspect you have very good reasons for that, > > most of config vars are at repo-level, not worktree-level, except > maybe submodule.* and something else. Yeah, that would have been my first guess too. > Technically we could use > "include.path" to point to a non-shared file, where we store > worktree-specific config. I like that, but am not sure how hard that would be to implement. >> but I believe >> that'll make multiple work trees surprise the user from time >> to time when used with submodules. Because initializing a >> submodule in one worktree initializes it in all other >> worktrees too (I suspect other users regard "git submodule >> init" being a worktree local command too). And setting >> "submodule..update" to "none" will also affect all >> other worktrees. But I'd need to have separate settings for >> our CI server, e.g. to checkout the sources without the >> largish documentation submodule in one test job (=worktree) >> while checking out the whole documentation for another job >> building the setup in another worktree. >> >> And if I understand the "checkout: reject if the branch is >> already checked out elsewhere" thread correctly, I won't be >> able to build "master" in two jobs at the same time? > > If you do "git checkout --to ... master^{}", it should run fine. So I'd have to teach our CI-server that incantation ... and must hope nothing else breaks because of the detached HEAD. > I'm > still considering doing something better with the read-only refs, but > haven't found time to really think it through yet. Hmm, what about different namespaces for the refs in the repo borrowed from? Maybe only when it is bare? Dunno ... >> Thanks. But I changed my mind about the details (now that I >> know about .git/config and multiple worktrees). I think you'd >> have to connect a .git directory in the submodule to the >> common git dir directly, as you cannot use the core.worktree >> setting (which could be different between commits due to >> renames) when putting it into /.git/modules. And >> then you couldn't remove or rename a submodule anymore, >> because that fails when it contains a .git directory. >> >> Seems like we should put a "Warning: may do unexpected things >> when used with submodules" (with some examples about what might >> happen) in the multiple worktrees documentation. And I don't >> believe anymore that teaching submodules to use the common git >> dir makes that much sense after I know about the restrictions >> it imposes. > > I'm ok with such a warning fwiw. I believe you'd need to prominently advertise that changing settings in .git/config affects all worktrees anyway to avoid surprising users (at least I didn't expect it ;-), so adding a word or to that this also impacts submodules should suffice.