From: Jeff King <peff@peff.net>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] init: disallow --separate-git-dir with bare repository
Date: Mon, 10 Aug 2020 05:56:48 -0400 [thread overview]
Message-ID: <20200810095648.GA37030@coredump.intra.peff.net> (raw)
In-Reply-To: <20200809225316.19503-1-sunshine@sunshineco.com>
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
next prev parent reply other threads:[~2020-08-10 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 22:53 [PATCH] init: disallow --separate-git-dir with bare repository Eric Sunshine
2020-08-10 9:56 ` Jeff King [this message]
2020-08-11 5:44 ` Eric Sunshine
2020-08-11 9:02 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200810095648.GA37030@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).