Am 05.12.2014 um 02:33 schrieb Duy Nguyen:
On Fri, Dec 5, 2014 at 3:06 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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.<name>.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 <worktree>/.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.
--
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