Re: [PATCH v3] config.c: split some variables to $GIT_DIR/config.worktree

[Max Kirillov <max@max630.net>]

On Tue, Mar 31, 2015 at 07:14:39PM +0700, Nguyễn Thái Ngọc Duy wrote:
>  The general principle is like in the last mail: .git/config is for
>  both shared and private keys of main worktree (i.e. nothing is
>  changed from today).  .git/worktrees/xx/config.worktree is for
>  private keys only (and private keys in .git/config are ignored)
>  
>  With this we don't have to bump core.repository_format_version for
>  main worktree because nothing is changed. There will be problems
>  with info/config.worktree:
> 
>   - it's customizable, so expect the user to break it (*)

I would rather say it's manual tuning rather than a break.

>   - if we add new stuff to the template, we'll need to help migrate
>     current info/core.worktree (which does not have new stuff).
>     Auto updating this file could be risky. I'm tend to just
>     warn the user that this and that keys should be included and let
>     them modify the file.

I don't think there even should be warning. Just don't
change the info/config.worktree in the existing repositories
and let users extend it as they feel a need for it.

Later there could be a tool (an option to git config for
example) which adds a variable or pattern to the
info/core.worktree and copied existing variable(s) from
commong config to worktree-specific ones.

....

> diff --git a/config.c b/config.c
> index 15a2983..3857023 100644
> --- a/config.c
> +++ b/config.c
....
> @@ -1932,6 +2002,23 @@ int git_config_set_multivar_in_file(const char *config_filename,
>  
>  	store.multi_replace = multi_replace;
>  
> +	if (git_common_dir_env && is_config_local(key)) {
> +		if (!config_filename)
> +			config_filename = filename_buf = git_pathdup("config.worktree");
> +		/* cheap trick, but should work 90% of time */
> +		else if (!ends_with(config_filename, ".worktree"))
> +			die("%s can only be stored in %s",
> +			    key, git_path("config.worktree"));

Is `config_filename` set only for cases when config file is
explicitly set for "git config" command with "--file"
option? Then probably here should not be any intelligence at
all; if user resort to manual picking the file he must be
allowed to do stupid things.

-- 
Max