Thread (35 messages) 35 messages, 3 authors, 2016-06-15

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

From: Max Kirillov <hidden>
Date: 2016-06-15 23:07:22

On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:
On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov [off-list ref] wrote:
quoted
Using builtin defaults might be confusing for users -
editing the info/config.worktree they must keep in mind the
list of defaults (which they seem to don't know).
All per-worktree variables are marked so in config.txt
If I were user I would like the list to be more explicit.
quoted
Also, if
anybody wants to extend the default list (like myself, for
submodules), should they edit the info/config.worktree in
provided template of extend the builtin list? What was wrong
with the default in template?
Suppose you introduce a new
per-worktree variable in the new git version. If it's in the builtin
list, we don't have to update every repo's info/config,worktree.
But how do you see it? Let's, for example, git-N consider
some variable as per-repository, and user does have it their
.git/config. Then git-N+1 considers it as per-worktree. How
does it find the variable while opening some existing
worktree? Then, if user sets the variable in some worktree
using git-N+1, git-N will no longer be able to see the
correct variable value. Does this mean that any change in
builtin list should cause repository incompatibility?

With defaults written in the info/config.worktree file the
issue do not exist at all: you can open repository created
with a git version with some default list of per-worktree
veriables with a version with other default list. It all
would work.

If user decides to change the actual list of default
per-worktree variable it is always can be done explcitly,
with some provided convenience command for example.

-- 
Max
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help