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