Re: [PATCH v6 3/6] config: add repo_config_set_worktree_gently()

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2022, 16:45 UTC
Message-ID: <xmqqczjuwtz8.fsf@gitster.g>
In-Reply-To: <2b88fa25-ec40-6416-05c8-81789a415844@gmail.com>

Derrick Stolee <stolee@gmail.com> writes:

> True, they could be split. The reason to create the _multivar_
> version is for the case that worktree config is not specified,
> so that is the only caller at the moment.

Sorry, but I am not following this part.

> This is an interesting idea. This would require creating a list
> of "should be per-worktree" config keys that are checked within
> the different *_config_set_* methods.

Yes.

> The biggest technical hurdle is that the multivar versions might
> need to send a subset of the given config into the worktree
> config and the rest to the common config.

Yes, instead of having the caller do it.

> Let's see how this progresses in the future, and whether we
> have more config that we believe _must_ be stored on a per-
> worktree basis. At that point, we can see whether the current
> "distributed responsibility" model is too cumbersome.

It is not too distributed, which is a saving grace. The callers know they are setting core.sparseCheckout* and they are responsible to call the per-worktree version. It would be like having in ref API an update_HEAD() helper for modifying HEAD, instead of having a more generic update_ref() that can modify any ref and pass "HEAD" as an argument to the latter. The caller needs to know a bit more details about what needs to happen when dealing with a special thing, but the special case knowledge is fairly concentrated.