git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, git@drmicha.warpmail.net, max.nordlund@sqore.com
Subject: Re: [PATCH v2 2/3] init: do not set core.worktree more often than necessary
Date: Wed, 21 Sep 2016 11:44:12 -0700	[thread overview]
Message-ID: <xmqqd1jx854z.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160921112939.3444-3-pclouds@gmail.com> ("Nguyễn Thái Ngọc Duy"'s message of "Wed, 21 Sep 2016 18:29:38 +0700")

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> When "git init" is called with GIT_WORK_TREE environment set, we want to
> keep this worktree's location in core.worktree so the user does not have
> to set the environment again and again. See ef6f0af (git-init: set
> core.worktree if GIT_WORK_TREE is specified - 2007-07-04)
>
> We detect that by this logic (in needs_work_tree_config): normally
> worktree's top dir would contains ".git" directory, if this is not true,

s/contains/contain/;

> worktree is probably set to elsewhere by the user.
>
> Unfortunately when it calls get_git_dir() it does not take ".git" files
> into account. When we find a .git file, we immediately follow the file
> until we find the real ".git" directory. The location of this first
> ".git" file is lost.
>
> The .git file would satisfy the logic above and not create
> core.worktree (correct). But because the final .git's location is used,
> needs_work_tree_config() is misled and creates core.worktree anyway.

The above explanation makes it sound like the correct fix belongs to
needs_work_tree_config(), though.

I am starting to wonder if what ef6f0af did was misguided and we are
better off without setting core.worktree ourselves, but that is a
different issue.

> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index d5d7558..0d5cc76 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -23,6 +23,7 @@ static int init_is_bare_repository = 0;
>  static int init_shared_repository = -1;
>  static const char *init_db_template_dir;
>  static const char *git_link;
> +static const char *original_git_dir;
>  
>  static void copy_templates_1(struct strbuf *path, struct strbuf *template,
>  			     DIR *dir)
> @@ -263,7 +264,7 @@ static int create_default_files(const char *template_path)
>  		/* allow template config file to override the default */
>  		if (log_all_ref_updates == -1)
>  			git_config_set("core.logallrefupdates", "true");
> -		if (needs_work_tree_config(get_git_dir(), work_tree))
> +		if (needs_work_tree_config(original_git_dir, work_tree))
>  			git_config_set("core.worktree", work_tree);
>  	}
>  
> @@ -314,6 +315,8 @@ static void create_object_directory(void)
>  int set_git_dir_init(const char *git_dir, const char *real_git_dir,
>  		     int exist_ok)
>  {
> +	original_git_dir = xstrdup(real_path(git_dir));
> +
>  	if (real_git_dir) {
>  		struct stat st;

The function being extern bothers me.  The create_default_files()
function, which is the only thing consumes this variable, is called
only from init_db(), and I'd prefer to see some way to guarantee
that everybody who calls init_db() calls set_git_dir_init()
beforehand.  Right now, cmd_init_db() and cmd_clone() are the only
ones that call init_db() and they both call set_dir_git_init(); if a
new caller starts calling init_db() and forgets to call the other
one, that caller will be buggy.

Perhaps a comment before init_db() to tell callers to always call
the other one is the least thing necessary?

> diff --git a/t/t0001-init.sh b/t/t0001-init.sh
> index 488564b..b8fc588 100755
> --- a/t/t0001-init.sh
> +++ b/t/t0001-init.sh
> @@ -400,9 +400,11 @@ test_expect_success 're-init from a linked worktree' '
>  		test_commit first &&
>  		git worktree add ../linked-worktree &&
>  		mv .git/info/exclude expected-exclude &&
> +		cp .git/config expected-config &&
>  		find .git/worktrees -print | sort >expected &&
>  		git -C ../linked-worktree init &&
>  		test_cmp expected-exclude .git/info/exclude &&
> +		test_cmp expected-config .git/config &&
>  		find .git/worktrees -print | sort >actual &&
>  		test_cmp expected actual
>  	)

  reply	other threads:[~2016-09-21 18:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 12:35 Bug with git worktrees and git init Max Nordlund
2016-08-23 15:21 ` Michael J Gruber
2016-08-24  9:35   ` Duy Nguyen
2016-09-08 13:47     ` [PATCH 0/3] Fix git-init in linked worktrees Nguyễn Thái Ngọc Duy
2016-09-08 13:47       ` [PATCH 1/3] init: correct re-initialization from a linked worktree Nguyễn Thái Ngọc Duy
2016-09-08 19:37         ` Junio C Hamano
2016-09-09 10:36           ` Duy Nguyen
2016-09-08 13:47       ` [PATCH 2/3] t0001: work around the bug that reads config file before repo setup Nguyễn Thái Ngọc Duy
2016-09-08 19:44         ` Junio C Hamano
2016-09-08 20:02         ` Jeff King
2016-09-09 10:32           ` Duy Nguyen
2016-09-09 11:22             ` Jeff King
2016-09-09 17:45               ` Jacob Keller
2016-09-08 13:47       ` [PATCH 3/3] init: do not set core.worktree more often than necessary Nguyễn Thái Ngọc Duy
2016-09-08 19:54         ` Junio C Hamano
2016-09-09 10:33           ` Duy Nguyen
2016-09-21 11:29       ` [PATCH v2 0/3] Fix git-init in linked worktrees Nguyễn Thái Ngọc Duy
2016-09-21 11:29         ` [PATCH v2 1/3] init: correct re-initialization from a linked worktree Nguyễn Thái Ngọc Duy
2016-09-21 11:29         ` [PATCH v2 2/3] init: do not set core.worktree more often than necessary Nguyễn Thái Ngọc Duy
2016-09-21 18:44           ` Junio C Hamano [this message]
2016-09-22 10:06             ` Duy Nguyen
2016-09-22 17:27               ` Junio C Hamano
2016-09-23 11:12                 ` [PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one Nguyễn Thái Ngọc Duy
2016-09-23 15:18                   ` Junio C Hamano
2016-09-23 22:53                   ` Junio C Hamano
2016-09-24 18:55                     ` Junio C Hamano
2016-09-25  3:13                       ` Duy Nguyen
2016-09-25  3:14                         ` [PATCH v3 1/5] init: correct re-initialization from a linked worktree Nguyễn Thái Ngọc Duy
2016-09-25  3:14                           ` [PATCH v3 2/5] init: call set_git_dir_init() from within init_db() Nguyễn Thái Ngọc Duy
2016-09-25  3:14                           ` [PATCH v3 3/5] init: kill set_git_dir_init() Nguyễn Thái Ngọc Duy
2016-09-25  3:14                           ` [PATCH v3 4/5] init: do not set unnecessary core.worktree Nguyễn Thái Ngọc Duy
2016-09-25  3:14                           ` [PATCH v3 5/5] init: kill git_link variable Nguyễn Thái Ngọc Duy
2016-09-21 11:29         ` [PATCH v2 3/3] init: reuse original_git_dir in set_git_dir_init() Nguyễn Thái Ngọc Duy
2016-09-21 18:18         ` [PATCH v2 0/3] Fix git-init in linked worktrees Junio C Hamano

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=xmqqd1jx854z.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=max.nordlund@sqore.com \
    --cc=pclouds@gmail.com \
    /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).