git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Max Kirillov <max@max630.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [PATCH v3] config.c: split some variables to $GIT_DIR/config.worktree
Date: Fri, 3 Apr 2015 17:30:58 +0700	[thread overview]
Message-ID: <CACsJy8C=MPLyba68ttQ2hhrM7bg8E-tEG-0kUjTLnNMMbX0MUQ@mail.gmail.com> (raw)
In-Reply-To: <20150401205644.GA3656@wheezy.local>

On Thu, Apr 2, 2015 at 3:56 AM, Max Kirillov <max@max630.net> wrote:
> 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.

But if the user accidentally deletes core.worktree then something will 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.

I was thinking "git checkout --to" would do this. It checks if the
main worktree has info/core.worktree, if not, re-init the repo to add
this file from default template.

>> @@ -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.

Yes. It may make sense in the previous versions where this feature
could work in a normal worktree, but when it becomes
multiworktree-specific, I guess we can drop this.
-- 
Duy

  reply	other threads:[~2015-04-03 10:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-08 13:16 [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 1/3] config.c: new config namespace worktree.* stored in $GIT_DIR/config.worktree Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 2/3] setup: add worktree.path to shadow core.worktree Nguyễn Thái Ngọc Duy
2015-02-08 13:16 ` [PATCH 3/3] submodule: use worktree.path instead of core.worktree Nguyễn Thái Ngọc Duy
2015-02-08 17:36 ` [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees Jens Lehmann
2015-02-08 17:41   ` Jens Lehmann
2015-02-09  9:35   ` Duy Nguyen
2015-03-18 21:33   ` per-repository and per-worktree config variables Max Kirillov
2015-03-24 13:48     ` Duy Nguyen
2015-03-26 12:04       ` [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree Nguyễn Thái Ngọc Duy
2015-03-26 22:19         ` Max Kirillov
2015-03-29  1:25           ` Duy Nguyen
2015-03-30 21:26             ` Max Kirillov
2015-03-31 12:14         ` [PATCH v3] " Nguyễn Thái Ngọc Duy
2015-03-31 12:17           ` Duy Nguyen
2015-04-01 20:56           ` Max Kirillov
2015-04-03 10:30             ` Duy Nguyen [this message]
2015-04-13 23:37           ` Max Kirillov
2015-04-18 11:10             ` Duy Nguyen
2015-04-20  2:51               ` Max Kirillov
2015-04-20  3:22                 ` Duy Nguyen
2015-03-25 21:33     ` per-repository and per-worktree config variables Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8C=MPLyba68ttQ2hhrM7bg8E-tEG-0kUjTLnNMMbX0MUQ@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=max@max630.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).