Christian Couder <christian.couder@xxxxxxxxx> writes: > Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx> > --- > Documentation/git-update-index.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt > index 7386c93162..e091b2a409 100644 > --- a/Documentation/git-update-index.txt > +++ b/Documentation/git-update-index.txt > @@ -171,6 +171,12 @@ may not support it yet. > given again, all changes in $GIT_DIR/index are pushed back to > the shared index file. This mode is designed for very large > indexes that take a significant amount of time to read or write. > ++ > +These options take effect whatever the value of the `core.splitIndex` > +configuration variable (see linkgit:git-config[1]). Doesn't the "whatever..." clause in this sentence lack its verb (presumably, "is", right after "variable")? > +emitted when the change goes against the configured value, as the > +configured value will take effect next time the index is read and this > +will remove the intended effect of the option. It feels somewhat strange to see a warning in this case. If the user configures the system to usually do X, and issues a command that explicitly does Y (or "not-X"), we do not warn for the command invocation if it is a single-shot operation. That's the usual "command line overrides configuration" an end-user expects. I think you made this deviate from the usual end-user expectation because it is unpredictable when the configuration kicks in the next time to undo the effect of this command line request. And I agree that it is a very un-nice thing to do to the users if we did not warn here, if we are to keep that unpredictableness. But stepping back a bit, we know the user's intention is that with "--split-index" the user wants to use the split index, even though the user may have configuration not to use the split index. Don't we want to honor that intention? In order to honor that intention without getting confused by the configured variable to tell us not to split, another way is to destroy that unpredictableness. For that, shouldn't we automatically remove the configuration that says "do not split" (by perhaps set it to "do split")? Doing so still may need a warning that says "we disabled your previously configured setting while at it", but it would be much better than a warning message that essentially says "we do it once, but we will disobey you at an unpredictable time", I would think.