On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote: > Am 01.12.2012 18:49, schrieb W. Trevor King: > > I think removing `init` will cause some compatibility issues anyway, > > so I was re-imaging how you do it. I don't think update='none' and > > "don't populate my submodule" are distinct ideas, while a locally > > configured url="somwhere" and "please populate my submodule" are (with > > the blank-url case defaulting to the superproject itself). > > Why would we want to remove "init"? It still has to copy the "url" > setting (and it would be a compatibility nightmare if we would change > that, imagine different git versions used on the same work tree). In my init-less rewrite, it doesn't have to copy the url setting. People using older versions of Git would need to run `init` using their old version. Having the url defined in .git/config won't break my init-less submodule commands, it just means that the value in .gitmodules will be masked. > >> What real world problems do we have with the current init/sync that > >> this approach would solve? > > > > I don't have any, but in my `update --remote` series I'm adding two > > new config options that are handled differently (define in > > .gitmodules, override in superproject .git/config) than existing > > submodules options. > > No, they're not. They are just handled differently than "url" and > "update", but will behave just like "fetchRecurseSubmodules" and > "ignore" do since day one. And as I explained in another mail I > think "url" is special and "update" should be change to behave like > the other two some day. I somehow missed those earlier. Thanks for correcting my tunnel vision. This makes me much happier about postponing the init-removal. 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
Attachment:
signature.asc
Description: OpenPGP digital signature