Am 02.12.2014 um 23:16 schrieb Max Kirillov:
On Tue, Dec 02, 2014 at 09:45:24PM +0100, Jens Lehmann wrote:
But, while hacking the submodule init I became more
convinced that the modules directory should be common and
submodules in checkout should be a checkouts of the
submodule. Because this is looks like concept of
submodules, that they are unique for the lifetime of
repository, even if they do not exist in all revisions.
And if anybody want to use fully independent checkout
they can be always checked out manually. Actually, after
a submodule is initialized and have a proper gitlink, it
can be updated and inquired regardless of where it points
to.
If I understand you correctly you want to put the
submodule's common git dir under the superproject's common
git dir. I agree that that makes most sense as the
default, but having the possibility to use a common git
dir for submodule's of different superprojects would be
nice to have for some setups, e.g. CI-servers. But that
can be added later.
So far there is no separation of .git/config for different
worktrees. As submodules rely on the config their separation
cannot be done fully without changing that. So this should
be really left for some later improvements.
Wow, so the .git/config is shared between all worktrees? I
suspect you have very good reasons for that, 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?
So two reasons against using multiple worktrees on our CI
server to save quite some disk space :-(
Thanks. I just didn't quite understand why you had to do so many
changes to git-submodule.sh. Wouldn't it be sufficient to just
update module_clone()?
Thanks, I should try it.
Probably I had the opposite idea in mind - keep module_clone
as untouched as possible. Maybe I should see how it's going
to look if I move all worktrees logic there.
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.
Or am I misunderstanding anything?
--
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