Re: [PATCH v5] Add another option for receive.denyCurrentBranch

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 2, 2014, 00:51 UTC
Message-ID: <xmqqk32aoowa.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqr3wjnd65.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 16 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> +static const char *update_worktree(unsigned char *sha1)
>> +{
>> +...
>> +	const char *work_tree = git_work_tree_cfg ? git_work_tree_cfg : "..";
>
> I overlooked this one, but is there a reason why this has to look at
> an internal implementatino detail which is git_work_tree_cfg,
> instead of asking get_git_work_tree()?
>
> I am wondering if that reason is a valid rationale to fix whatever
> makes get_git_work_tree() unsuitable for this purpose.
>
> Cc'ing Duy who has been working on the part of the system to
> determine and set-up work-tree and git-dir.

Answering myself...

This is because you know receive-pack runs inside the $GIT_DIR, whether it is a bare or non-bare repository, so either core.worktree points at a directory that is otherwise unrelated to the $GIT_DIR (but is the correct $GIT_WORK_TREE), or the top of the working tree must be ".." for a non-bare repository. I haven't checked the code, but we probably are not even doing the repository/working-tree discovery to set up the data necessary for get_git_work_tree() to give us a correct answer.

Doing an optional set-up to make get_git_work_tree() work would involve more damage to the codebase than necessary, I would suspect, so let's keep this part of the code as-is.

That is, unless I am over-estimating the "damage" necessary.

Thanks.