Re: [PATCH] commit-graph: add new config for changed-paths & recommend it in scalar

[Junio C Hamano <gitster@pobox.com>]

Derrick Stolee <stolee@gmail.com> writes:

> One thing that is tricky about --[no-]changed-paths is that it is a
> "tri-state" argument due to 0087a87ba8 (commit-graph: persist
> existence of changed-paths, 2020-07-01):
>
>  * --changed-paths : Definitely write the data, even if it didn't
>    exist already.
>
>  * --no-changed-paths : Definitely _don't_ write the data, even if
>    it exists already.
>
>  * (not present) : Update filters that do exist, but don't write them
>    if they don't exist.

OK, so "--no-" is not the usual "no"; it is more like "strip
existing" that implies "even existing ones are getting nuked, there
is no way we write new ones".  OK, that may explain the construct I
found funny.  Thanks for clarifying.

> The situation that I wanted to think about was this:
>
>  * A user sets the config to 'true' in global config.
>  * They then set the config to 'false' in a specific repo.
>
> In this case, the 'false' _disables the config_ but doesn't cause
> any existing filters to be deleted.

Ouch, that hurts, as they expected this specific one would drop
existing filters but that does not happen.

Perhaps we need to strengthen the description of --no-* (if not
renaming it to --drop-* or something to clarify what it really
does).

At least the configuration needs to be explained not like: "setting
it to false is different from --no-changed-paths option".  The
documentation should not stop at saying what it is not, but should
also say what it does.  Perhaps "setting it to true is like always
giving --changed-paths, setting it to false stops writing new
changed paths filters, but without dropping existing changed paths
filters" or something along that line.

Thanks.