On Thu, Dec 4, 2014 at 10:06 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > 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. Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not. I have added a config variable submodule.updateIgnoringConfigUrl (because usually the submodule.<name>.url is what turns on the update). It looks working, maybe I even add setting the variable when chackout --to is used. > 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? You are alerady second person complaining about it, but I don't really see how this can be a problem. Make a branch 'master2', it's another 40 bytes. > So two reasons against using multiple worktrees on our CI > server to save quite some disk space :-( My use is not to save space (working tree files often takes more than the repository itself), but for development, I have like 3-5 checkouts usually, which used to be local clones, but not having to keep synching them is really life changing. > 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. I need to think more about it. > 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. btw, I thought even about making it an error to add/remove/(de)initialize submodule not in the main working tree. But I'm afraid it would not be considered appropriate for merging. -- Max -- 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