From: Phil Hord Date: Mon, 12 Dec 2011 21:16:19 GMT Subject: Re: [PATCH v4 2/2] push: teach --recurse-submodules the on-demand option Message-ID: In-Reply-To: <4E9DE883.9050105@web.de> On Tue, Oct 18, 2011 at 4:58 PM, Jens Lehmann wrote: > Am 18.10.2011 00:33, schrieb Junio C Hamano: >> The very first step for floating submodules support would be relatively >> simple. We could declare that an entry in the .gitmodules file in the >> superproject can optionally specify which branch needs to be checked out >> with something like: >> >>       [submodule "libfoo"] >>               branch = master >>                 path = include/foo >>                 url = git://foo.com/git/lib.git >> >> and when such an entry is defined, a command at the superproject level >> would largely ignore what is at include/foo in the tree object recorded in >> the superproject commit and in the index. When we show "git status" in the >> superproject, instead of using the commit bound to the superproject, we >> would use include/foo/.git/HEAD as the basis for detecting "local" changes >> to the submodule. > > Yup. And the presence of the "branch" config could tell "git submodule > update" to fetch and advance that branch to the tip every time it is run. > And it could tell the diff machinery (which is also used by status) to > ignore the differences between a submodule's HEAD and the SHA-1 in the > superproject (while still allowing to silence the presence of untracked > and/or modified files by using the diff.ignoreSubmodules option) and > fetch would just stop doing any on-demand action for such submodules. > Anything I missed? > >> We could even declare that the gitlink for such a >> submodule should record 0{40} SHA-1 in the superproject, but I do not >> think that is necessary. > > Me neither, e.g. the SHA-1 which was the submodules HEAD when it was added > should do nicely. And that would avoid referencing a non-existing commit > in case you later want to turn a floating submodule into an exact one. I'm sorry I missed this comment before. I hope we can allow storing the actual gitlink in the superproject for each commit even when we're using floating submodules. I thought-experimented with this a bit last year and came to the conclusion that I should be able to 'float' to tips (developer convenience) and also to store the SHA-1 of each gitlink through history (automated maybe; as-needed). The problem with "float-only" is that it loses history so, for example, git-bisect doesn't work. The problem with "float + gitlinks", of course, is that it looks like "not floating" to the developers (git-status is dirty unless overridden, etc.) Is there a deeper reason this wouldn't be possible? Phil