Re: bug: 'core.logallrefupdates' is not set by default in non-bare repository

From: Jeff King <peff@peff.net>
Date: Sep 2, 2016, 09:11 UTC
Message-ID: <20160902091130.jxckdeomw35eewky@sigill.intra.peff.net>
In-Reply-To: <1472806914.4680.50.camel@kaarsemaker.net>

On Fri, Sep 02, 2016 at 11:01:54AM +0200, Dennis Kaarsemaker wrote:

> Well, 'git init' is a valid operation to run inside an existing repo to
> reinitialize some bits, so we definitely need to not ignore the config
> once we're sure we're not creating a new repo.

Good point, I hadn't considered re-initializing.

For the follow-up patch I sent, where we check startup_info->have_repository, I think the right thing would probably be to call setup_git_directory() after seeing we are in a re-init case. Probably even the "gently" form, as I think you can "re-init" a partially corrupted repository.

Show 18 quoted lines

> > > @@ -500,7 +506,6 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
> > >  				 * and we know shared_repository should always be 0;
> > >  				 * but just in case we play safe.
> > >  				 */
> > > -				saved = get_shared_repository();
> > >  				set_shared_repository(0);
> > >  				switch (safe_create_leading_directories_const(argv[0])) {
> > >  				case SCLD_OK:
> > I don't know if anybody cares about being able to set core.sharedRepository
> > from ~/.gitconfig. It didn't work until v2.9.0 anyway (when I moved it
> > out of the repository-format check), but it seems like you _should_ be
> > able to set it and have it Just Work.
> > 
> > And in that case, this "we know shared_repository should always be 0" is
> > not true, and we would want to keep doing the save/set-to-0/restore
> > dance here.
> 
> We don't need to save if we throw away the cache below.

Yeah, you're right. Though I somehow lost my train of thought between the two paragraphs. I was thinking that we would want to actually respect the ~/.gitconfig setting for sharedrepository. Which would actually mean _dropping_ the save/zero/restore entirely, and just using the value we get from the config. But I guess the point here is to avoid s_c_l_d creating "shared" leading directories that are outside any repository. I could see an argument either way on whether that is the right thing to do when core.sharedRepository is set in ~/.gitconfig.

-Peff