Derrick Stolee <stolee@xxxxxxxxx> 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.
