Re: [PATCH] setup: allow cwd=.git w/ bareRepository=explicit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Kyle Lippincott via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> Teach git to not reject uses of git inside of the .git directory: check
> if cwd is .git (or a subdirectory of it) and allow it even if
> safe.bareRepository=explicit.

> diff --git a/setup.c b/setup.c
> index b38702718fb..b095e284979 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1371,7 +1371,8 @@ static enum discovery_result setup_git_directory_gently_1(struct strbuf *dir,
>  
>  		if (is_git_directory(dir->buf)) {
>  			trace2_data_string("setup", NULL, "implicit-bare-repository", dir->buf);
> -			if (get_allowed_bare_repo() == ALLOWED_BARE_REPO_EXPLICIT)
> +			if (get_allowed_bare_repo() == ALLOWED_BARE_REPO_EXPLICIT &&
> +			    !ends_with_path_components(dir->buf, ".git"))
>  				return GIT_DIR_DISALLOWED_BARE;
>  			if (!ensure_valid_ownership(NULL, NULL, dir->buf, report))
>  				return GIT_DIR_INVALID_OWNERSHIP;

I wish we had caught it much before we added DISALLOWED_BARE thing,
but I wonder how well would this escape-hatch interact with
secondary worktrees, where their git directory is not named ".git"
and not immediately below the root level of the working tree?

In a secondary worktree the root level of its working tree has a
file ".git", whose contents may look like

    gitdir: /home/gitster/git.git/.git/worktrees/git.old

where

 - /home/gitster/git.git/ is the primary worktree with the
   repository.

 - /home/gitster/git.git/.git/worktrees/git.old looks like a bare
   repository.

 - /home/gitster/git.git/.git/worktrees/git.old/gitdir gives a way
   to discover the secondary worktree, whose contents just records
   the path to the ".git" file, e.g., "/home/gitster/git.old/.git"
   that had "gitdir: ..." in it.

So perhaps we can also use the presence of "gitdir" file, check the
contents of it tn ensure that ".git" file there takes us back to
this (not quite) bare repository we are looking at, and allow access
to it, or something?

Thoughts?





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux