On Tue, Dec 27, 2016 at 8:07 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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")? I think that it is ok to have no verb here. My preferred online dictionary (http://www.wordreference.com/enfr/whatever) gives "We'll try to free the hostage whatever the cost." as an example with no verb, though I am not a native speaker. Also note that I mostly copied what I had already written for --(no-)untracked-cache: --untracked-cache:: --no-untracked-cache:: Enable or disable untracked cache feature. Please use `--test-untracked-cache` before enabling it. + These options take effect whatever the value of the `core.untrackedCache` configuration variable (see linkgit:git-config[1]). But a warning is 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. >> +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. We already discussed the warning issue for --(no-)untracked-cache, and I am just following the conclusions of that previous discussion about --(no-)untracked-cache. See the end of this message where you suggested the warning: https://public-inbox.org/git/xmqqlh8cg9y2.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ > 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. I also think it would be strange and user unfriendly for --untracked-cache and --split-index to behave differently, and I am reluctant at this point to rework the way it works for --untracked-cache. > 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. I wanted to do that for --untracked-cache around one year ago but in the following message: https://public-inbox.org/git/xmqqsi3ckadi.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ you wrote the following: "Why is it a good idea to allow an explicit operation from the command line to muck with the configuration? If the user wants to change the configuration permanently, "git config" has been there for the purpose for all the configuration variables to do so for almost forever. Why is it a good idea to make this variable so special that the user does not have to use "git config" but disable or enable it in some other way?" It feels strange that when I do things one way, you suggest another way, and the next time in a similar situation when I do things the way you suggested previously, then you suggest the way I did it initially the first time...