From: Jeff King <peff@peff.net>
Date: Tue, 11 Aug 2020 09:02:45 GMT
Subject: Re: [PATCH] init: disallow --separate-git-dir with bare repository
Message-ID: <20200811090245.GA2050353@coredump.intra.peff.net>
In-Reply-To: <CAPig+cSMzEuMYNnHhMGwqGFgjWfX0+j1KoOSK8V7Wav97p+UVw@mail.gmail.com>

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