Re: [RFC] remove/deprecate 'submodule init' and 'sync'
- From
W. Trevor King <wking@tremily.us>
- Date
- Dec 1, 2012, 18:16 UTC
- Message-ID
- <20121201181643.GF4823@odin.tremily.us>
- In-Reply-To
- <50BA4695.7030008@web.de>
On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:
Show 10 quoted lines
> 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.
Show 13 quoted lines
> >> 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