From: Jens Lehmann Date: Mon, 08 Dec 2014 20:40:59 GMT Subject: Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules Message-ID: <54860CDB.9090904@web.de> In-Reply-To: <20141207064230.GA9782@wheezy.local> Am 07.12.2014 um 07:42 schrieb Max Kirillov: > On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: >> Am 05.12.2014 um 07:32 schrieb Max Kirillov: >>> 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..url is what turns on the update). It looks working, >>> maybe I even add setting the variable when chackout --to is used. > >> But it's not only submodule..url, the list goes on with >> update, fetch & ignore and then there are the global options >> like diff.submodule, diff.ignoreSubmodules and some more. > > I believe that parameters are important for some use, but I > know several tesns of git users who have no idea bout them, > and I myself only learned about them while working on this. But we still want to support them all properly, no? > To have some a submodule not initialized in some sorktree is > what I really need. I was sure before it is managed by > having the submodule checked out. Probably I just did not > run `submodule update` in the worktree where did not use > submodules, but I cannot rely on it. I see now from > 211b7f19c7 that adding parameter for all updates will break > the initalization. Maybe it would be better to have a > runtime argument: `git submodule update --ignore-config-url` Huh? I think we already have that: If you ignore the url config it's as if the submodule was never initialized, so you can just *not* run the "git submodule update" command at all to get that effect. No new option needed ;-) >> Thanks to you and Duy for discussing this with me! I'd sum it >> up like this: >> >> *) Multiple worktrees are meant to couple separate worktrees >> with a single repository to avoid having to push and fetch >> each time to sync refs and also to not having to sync >> settings manually (with the benefit of some disk space >> savings). That's a cool feature and explains why a branch >> should be protected against being modified in different >> worktrees. > > I should notify that I am not the author of the feature, > maybe Duy have some other vision. > >> The first level submodule settings are shared between the >> multiple worktrees; submodule objects, settings and refs >> aren't (because the .git/modules directory isn't shared). >> >> Looks like that would work with just what we have now, no? > > Yes, very much like what I proposed in $gmane/258173, but I > need to have something about preventing checkout. And I > should review what I've done since that, maybe there are > more things to fix. Hmm, I do not get the "preventing checkout" part. If you ran "git submodule init " in just one of the multiple work trees a later "git submodule update" in any of the multiple work trees will checkout the submodule there. The only way I can imagine to change that is to implement separate worktree configurations for each of the multiple worktrees. >> *) I'd love to see a solution for sharing the object database >> between otherwise unrelated clones of the same project (so >> that fetching in one clone updates the objects in the common >> dir and gc cannot throw anything away used by one of the >> clones). But I'd expect a bare repository as the common one >> where we put the worktrees refs into their own namespaces. > > There is a GIT_NAMESPACE already, maybe it should be just > extended to work with all commands? As you already noticed, it isn't a solution for my problem. > btw, have you tried alternates? It does reduce the number of > objects you need to keep very strongly. You can put in the > alternate store only released branches which are guaranteed > to be not force-updated, to avoid issues with missing > objects, and it still helps. Which is exactly what we do *not* want to do on a CI server, its purpose is to endlessly build development branches that are force-updated on a regular basis.