diff mbox series

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

Message ID 20200809225316.19503-1-sunshine@sunshineco.com (mailing list archive)
State Accepted
Commit ccf236a23adb5cfb4e5285daad083149458d7828
Headers show
Series init: disallow --separate-git-dir with bare repository | expand

Commit Message

Eric Sunshine Aug. 9, 2020, 10:53 p.m. UTC
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(+)

Comments

Jeff King Aug. 10, 2020, 9:56 a.m. UTC | #1
On Sun, Aug 09, 2020 at 06:53:16PM -0400, Eric Sunshine wrote:

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

> 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, 5:44 a.m. UTC | #2
On Mon, Aug 10, 2020 at 5:56 AM Jeff King <peff@peff.net> wrote:
> 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,

> > 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, 9:02 a.m. UTC | #3
On Tue, Aug 11, 2020 at 01:44:00AM -0400, Eric Sunshine wrote:

> > 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. :)

> > 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
diff mbox series

Patch

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 &&