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.<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.
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 <path>" 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
