Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 18.09.2013 12:12, schrieb Tay Ray Chuan:
> On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> 
> Thanks Jens for having a look!
> 
>> Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
>>> When 'update' is run with no path in a repository with uninitialized
>>> submodules, the program terminates with no output, and zero status code.
>>> Be more helpful to users by mentioning this.
>>
>> [snip] it would be rather nasty to error out on every submodule
>> update.
> 
> Just to be sure we're on the right page, with this patch, the 'update'
> command still exits with status code zero (non-error), so this patch
> doesn't make it error out.

Ok, sorry for the confusion. But I still think we should not change
the default to print these messages, but make it an opt-in. And the
commit message (and maybe the documentation too) should talk about
the use cases where this makes sense.

>> After the 'autoinit' configuration (which lets upstream hint that
>> certain submodules should be initialized on clone) has materialzed we
>> might want to enable this error for these specific submodules.
> 
> That's cool, I'm looking forward to this. Could you point me to
> somewhere detailing this?

Not yet. I'm still wrestling with the autoupdate series, which is
the logical step before autoinit. autoupdate enables to configure
that initialized submodules are updated on checkout, reset, merge
and all the other work tree manipulating commands. autoinit then
also clones the repos of submodules into .git/modules and inits
them in .git/config, so that autoupdate will automagically populate
them. Unfortunately autoupdate is a rather largish series touching
lots of commands and needing tons of tests ...

> But in the meantime, on top of the advice.* config, how about having a
> submodule.<name>.ignoreUninit config to disable the message on a
> per-submodule basis?

I'd not add such an option unless users request it because it helps
their not-so-terribly-specific use case.

>> But in
>> any case the error message should contain a hint on how you can get
>> rid of the error in case you know what you are doing ;-).
> 
> The message does mention that you can throw in an --init to fix the
> problem. This "hint" is similar to what git-submodule prints when a
> <path> is passed (see region at line 807).

But for a lot of users that isn't a solution, as they never want to
init it, they want to ignore it. And if you explicitly ask to update
a special submodule, that message is ok.