Thread (1 message) 1 message, 1 author, 2022-02-10

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

From: Junio C Hamano <hidden>
Date: 2022-02-10 16:45:53

Derrick Stolee [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help