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
