threads / patch / 54011

patchinit: disallow --separate-git-dir with bare repository

Subject: [PATCH] init: disallow --separate-git-dir with bare repository

## tl;dr

4 messages between Aug 9, 2020 and Aug 11, 2020. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Eric Sunshine· Aug 9, 2020, 22:53 UTC · lore

The purpose of "git init --separate-git-dir" is to separate the repository from the worktree. This is true even when --separate-git-dir is used on an existing worktree, in which case, it moves the .git/ subdirectory to a new location outside the worktree.

However, an outright bare repository (such as one created by "git init --bare"), has no worktree, so using --separate-git-dir to separate it from its non-existent worktree is nonsensical. Therefore, make it an error to use --separate-git-dir on a bare repository.

Implementation note: "git init" considers a repository bare if told so explicitly via --bare or if it guesses it to be so based upon heuristics. In the explicit --bare case, a conflict with --separate-git-dir is easy to detect early. In the guessed case, however, the conflict can only be detected once "bareness" is guessed, which happens after "git init" has begun creating the repository. Technically, we can get by with a single late check which would cover both cases, however, erroring out early, when possible, without leaving detritus provides a better user experience.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
Notes:
    I ran across this while working on a worktree-related topic dealing
    with --separate-git-dir. Closing this loophole eliminates some
    potentially strange and unworkable cases that the other topic might
    otherwise encounter. Even though this change is tangentially related
    to the other topic, it's also sufficiently standalone to post
    separately; plus, I want to get feedback on it early since I'm not
    100% happy with checking for the conflict between --separate-git-dir
    and a bare repository in two separate places (though, I can live
    with it).
 builtin/init-db.c |  5 +++++
 t/t0001-init.sh   | 13 +++++++++++++
 2 files changed, 18 insertions(+)
Show changes to 2 files +18 −0

builtin/init-db.c, t/t0001-init.sh

diff --git a/builtin/init-db.c b/builtin/init-db.c
index cee64823cb..60e5c14169 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -568,6 +568,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
 
 	argc = parse_options(argc, argv, prefix, init_db_options, init_db_usage, 0);
 
+	if (real_git_dir && is_bare_repository_cfg == 1)
+		die(_("--separate-git-dir and --bare are mutually exclusive"));
+
 	if (real_git_dir && !is_absolute_path(real_git_dir))
 		real_git_dir = real_pathdup(real_git_dir, 1);
 
@@ -663,6 +666,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
 				   get_git_work_tree());
 	}
 	else {
+		if (real_git_dir)
+			die(_("--separate-git-dir incompatible with bare repository"));
 		if (work_tree)
 			set_git_work_tree(work_tree);
 	}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 6d2467995e..5c585f7fcb 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -316,6 +316,19 @@ test_expect_success 'init with separate gitdir' '
 	test_path_is_dir realgitdir/refs
 '
 
+test_expect_success 'explicit bare & --separate-git-dir incompatible' '
+	test_must_fail git init --bare --separate-git-dir goop.git bare.git 2>err &&
+	test_i18ngrep "mutually exclusive" err
+'
+
+test_expect_success 'implicit bare & --separate-git-dir incompatible' '
+	test_when_finished "rm -rf bare.git" &&
+	mkdir -p bare.git &&
+	test_must_fail env GIT_DIR=. \
+		git -C bare.git init --separate-git-dir goop.git 2>err &&
+	test_i18ngrep "incompatible" err
+'
+
 test_lazy_prereq GETCWD_IGNORES_PERMS '
 	base=GETCWD_TEST_BASE_DIR &&
 	mkdir -p $base/dir &&
-- 
2.28.0.220.ged08abb693
Jeff King· Aug 10, 2020, 09:56 UTC · re: Eric Sunshine · lore

Re: [PATCH] init: disallow --separate-git-dir with bare repository

On Sun, Aug 09, 2020 at 06:53:16PM -0400, Eric Sunshine wrote:
Show 9 quoted lines
> The purpose of "git init --separate-git-dir" is to separate the
> repository from the worktree. This is true even when --separate-git-dir
> is used on an existing worktree, in which case, it moves the .git/
> subdirectory to a new location outside the worktree.
> 
> However, an outright bare repository (such as one created by "git init
> --bare"), has no worktree, so using --separate-git-dir to separate it
> from its non-existent worktree is nonsensical. Therefore, make it an
> error to use --separate-git-dir on a bare repository.

I agree that it seems like nonsense. I'm a little curious what it happens to do today, just because I'd wonder if it could possibly be of any use to somebody.

Show 9 quoted lines
> Implementation note: "git init" considers a repository bare if told so
> explicitly via --bare or if it guesses it to be so based upon
> heuristics. In the explicit --bare case, a conflict with
> --separate-git-dir is easy to detect early. In the guessed case,
> however, the conflict can only be detected once "bareness" is guessed,
> which happens after "git init" has begun creating the repository.
> Technically, we can get by with a single late check which would cover
> both cases, however, erroring out early, when possible, without leaving
> detritus provides a better user experience.

I think we'd clean up that detritus with our atexit handler, but I like the extra check here. It lets us give a slightly more specific message when we can catch it early ("these two options are incompatible").

>  builtin/init-db.c |  5 +++++
>  t/t0001-init.sh   | 13 +++++++++++++
>  2 files changed, 18 insertions(+)

The patch itself looks good, assuming my "I'd wonder..." line of inquiry above produces nothing of value. :)

-Peff
Eric Sunshine· Aug 11, 2020, 05:44 UTC · re: Jeff King · lore

Re: [PATCH] init: disallow --separate-git-dir with bare repository

On Mon, Aug 10, 2020 at 5:56 AM Jeff King <peff@peff.net> wrote:
Show 9 quoted lines
> On Sun, Aug 09, 2020 at 06:53:16PM -0400, Eric Sunshine wrote:
> > However, an outright bare repository (such as one created by "git init
> > --bare"), has no worktree, so using --separate-git-dir to separate it
> > from its non-existent worktree is nonsensical. Therefore, make it an
> > error to use --separate-git-dir on a bare repository.
>
> I agree that it seems like nonsense. I'm a little curious what it
> happens to do today, just because I'd wonder if it could possibly be of
> any use to somebody.

The current behavior does some goofy stuff which I can't imagine being useful to anyone. For instance:

    % git init --bare --separate-git-dir bar.git foo.git
    % ls -1
    bar.git
    foo.git
    % cat foo.git
    gitdir: /.../bar.git
    %

So, I just initialized a bare repository "foo.git" which isn't actually a directory at all but instead is just a 'gitlink' file. What can I do with file "foo.git"? Not a whole lot. "bar.git" is the actual repository.

The case of re-initializing a bare repository with --separate-git-dir is even weirder:

    % rm -rf foo.git bar.git
    % git init --bare foo.git
    % # ... add some commits ...
    % git -C foo.git rev-parse master
    86e28bed5ac8f5ea774690b4fc0eddb434800e9e
    % git -C foo.git init --separate-git-dir ../bar.git
    % ls -FA bar.git
    HEAD         config       hooks/       objects/
    branches/    description  info/        refs/
    % ls -FA foo.git
    .git         branches/    description  info/        refs/
    HEAD         config       hooks/       objects/
    % cat foo.git/.git
    gitdir: /.../bar.git
    % git -C bar.git rev-parse master --
    fatal: bad revision 'master'
    % git -C foo.git rev-parse master --
    fatal: bad revision 'master'
    % rm foo.git/.git
    % git -C foo.git rev-parse master
    86e28bed5ac8f5ea774690b4fc0eddb434800e9e
    %

So, the repository doesn't actually move at all; it stays at "foo.git". And "bar.git", even though it looks like a repository, is actually empty; all the objects are still in "foo.git". Plus "foo.git" is _broken_ by the ".git" file which --separate-git-dir placed there.

So, it's meaningless and perhaps destructive behavior using --separate-git-dir with a bare repository,

Show 13 quoted lines
> > Implementation note: "git init" considers a repository bare if told so
> > explicitly via --bare or if it guesses it to be so based upon
> > heuristics. In the explicit --bare case, a conflict with
> > --separate-git-dir is easy to detect early. In the guessed case,
> > however, the conflict can only be detected once "bareness" is guessed,
> > which happens after "git init" has begun creating the repository.
> > Technically, we can get by with a single late check which would cover
> > both cases, however, erroring out early, when possible, without leaving
> > detritus provides a better user experience.
>
> I think we'd clean up that detritus with our atexit handler, but I like
> the extra check here. It lets us give a slightly more specific message
> when we can catch it early ("these two options are incompatible").
With only the latter (after-the-fact) check:
    % git init --bare --separate-git-dir bar.git foo.git
    fatal: --separate-git-dir incompatible with bare repository
    % ls -1
    foo.git
    % ls -A foo.git/
    %

It leaves the directory "foo.git" around, though the directory is empty. With the earlier check in place, it avoids leaving that empty directory.

> The patch itself looks good, assuming my "I'd wonder..." line of inquiry
> above produces nothing of value. :)

I can't find any value in the current behavior, so I'm pretty well convinced that this patch is desirable (even if I don't quite like repeating the check).

I didn't add any of the above explanation-by-examples to the commit message because it seemed too much detail.

Jeff King· Aug 11, 2020, 09:02 UTC · re: Eric Sunshine · lore

Re: [PATCH] init: disallow --separate-git-dir with bare repository

On Tue, Aug 11, 2020 at 01:44:00AM -0400, Eric Sunshine wrote:
Show 7 quoted lines
> > I agree that it seems like nonsense. I'm a little curious what it
> > happens to do today, just because I'd wonder if it could possibly be of
> > any use to somebody.
> 
> The current behavior does some goofy stuff which I can't imagine being
> useful to anyone. For instance:
> [...]

OK, that's sufficiently brain-dead that I agree nobody will be sad to see it go. Thanks for indulging me. :)

Show 16 quoted lines
> > I think we'd clean up that detritus with our atexit handler, but I like
> > the extra check here. It lets us give a slightly more specific message
> > when we can catch it early ("these two options are incompatible").
> 
> With only the latter (after-the-fact) check:
> 
>     % git init --bare --separate-git-dir bar.git foo.git
>     fatal: --separate-git-dir incompatible with bare repository
>     % ls -1
>     foo.git
>     % ls -A foo.git/
>     %
> 
> It leaves the directory "foo.git" around, though the directory is
> empty. With the earlier check in place, it avoids leaving that empty
> directory.

Ah, right. git-clone has some magic auto-cleanup for signals/atexit, but git-init does not. It might be worth adding that, but it's definitely outside the scope of your patch.

-Peff

← back to recent threads