Am 18.09.2013 12:12, schrieb Tay Ray Chuan: > On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html