git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] init: disallow --separate-git-dir with bare repository
@ 2020-08-09 22:53 Eric Sunshine
  2020-08-10  9:56 ` Jeff King
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Sunshine @ 2020-08-09 22:53 UTC (permalink / raw)
  To: git; +Cc: Eric Sunshine

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(+)

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


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] init: disallow --separate-git-dir with bare repository
  2020-08-09 22:53 [PATCH] init: disallow --separate-git-dir with bare repository Eric Sunshine
@ 2020-08-10  9:56 ` Jeff King
  2020-08-11  5:44   ` Eric Sunshine
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff King @ 2020-08-10  9:56 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: git

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] init: disallow --separate-git-dir with bare repository
  2020-08-10  9:56 ` Jeff King
@ 2020-08-11  5:44   ` Eric Sunshine
  2020-08-11  9:02     ` Jeff King
  0 siblings, 1 reply; 4+ messages in thread
From: Eric Sunshine @ 2020-08-11  5:44 UTC (permalink / raw)
  To: Jeff King; +Cc: Git List

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] init: disallow --separate-git-dir with bare repository
  2020-08-11  5:44   ` Eric Sunshine
@ 2020-08-11  9:02     ` Jeff King
  0 siblings, 0 replies; 4+ messages in thread
From: Jeff King @ 2020-08-11  9:02 UTC (permalink / raw)
  To: Eric Sunshine; +Cc: Git List

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-08-11  9:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-09 22:53 [PATCH] init: disallow --separate-git-dir with bare repository Eric Sunshine
2020-08-10  9:56 ` Jeff King
2020-08-11  5:44   ` Eric Sunshine
2020-08-11  9:02     ` Jeff King

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 NNTP newsgroup(s).