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.<name>.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.<name>.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. 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` > 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. > *) 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? 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. For example, the full git repository takes about 70mb, and if I put master to alternate store, the rest takes 7mb, and even if I clone all original repository, debian repository and msysgit repository, thay all take 15mb. It's without worktree, which takes 27mb :) -- 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