On Sun, Dec 02, 2012 at 04:11:59PM -0500, W. Trevor King wrote: > On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote: > > Am 01.12.2012 18:49, schrieb W. Trevor King: > > > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote: > > >> What real world problems do we have with the current init/sync that > > >> this approach would solve? > > > > > > I don't have any, ... > > > > We don't want to change working code and cause compatibility issues > > just because we /could/ do things differently, no? > > In principle, yes, but in this case I think changing the > implementation does not risk much in the way of compatibility issues > (it only hurts users who rely on `submodule init` setting > submodule..url for reasons of their own. A few of the existing > tests explictly check the url setting, so perhaps there are a number > of users who do require this side effect? > > I think this risk is outweighed by the benefits of having a clearer > activation option. For anyone interested in an implementation of my submodule..active proposal, I've posted an initial version: git://github.com/wking/git.git wtk/submodule.name.active I can re-post it here as a PATCH series, but I don't think we're at the level of patch-specific feedback yet. I'm currently pretty happy with it except for the last commit: HACK work around missing index entry for existing empty submodules To solve that cleanly, I'd need a solution to the commit-less existing repository problem which I mentioned earlier: On Sat, Dec 01, 2012 at 11:54:04AM -0500, W. Trevor King wrote: > I'm currently stuck with adding a commit-less existing repository as a > submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c > works with relative local path): > > $ mkdir -p super/sub > $ cd super > $ git init > $ (cd sub && git init) > $ git submodule add ./ sub > $ git status > # On branch master > # > # Initial commit > # > # Changes to be committed: > # (use "git rm --cached ..." to unstage) > # > # new file: .gitmodules > # > > What I'm missing is a gitlink form sub for 'Subproject commit > 00000...' or some such. When the subproject has an actual commit, > things work as expected: > > $ mkdir -p super/sub > $ cd super > $ git init > $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file) > $ git submodule add ./ sub > $ git status > # On branch master > # > # Initial commit > # > # Changes to be committed: > # (use "git rm --cached ..." to unstage) > # > # new file: .gitmodules > # new file: sub > # > > This means that module_list isn't aware of the empty submodule, when > the user has just explicitly added it. Fixing this would seem to need > either 'Subproject commit 00000...' as I suggested earlier, or an > adjustment to module_list that also spits out submodules that are in > .gitmodules but not in the index. Other than that, I think all the changes in the test suite are logically sound and unlikely to cause problems with existing usage. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy