Recovering from 'fatal: core.bare and core.worktree do not make sense'

Hi,

the other day I said 'git config core.worktree /somewhere' in a bare repo while thinking I was in a regular one, user error. The 'fatal: core.bare and core.worktree do not make sense' error from the next command made me realize immediately that I was wrong, that's good. However...

OK, let's have a look and recover from the situation:

    $ git config --edit
    fatal: core.bare and core.worktree do not make sense

Well, all was well before I set 'core.worktree', so let's unset it:

    $ git config --unset core.worktree
    fatal: core.bare and core.worktree do not make sense

Hmph, not expecting much, but how about unsetting the other variable?

    $ git config --unset core.bare
    fatal: core.bare and core.worktree do not make sense

Good, at least it's pretty consistent, though I still don't get what 'git config' has to do with the worktree that is so important that it has to bail out. Time to look for help:

    $ git help config
    fatal: core.bare and core.worktree do not make sense

WTF :) Alright, I give up:

    $ vim config
    $ # happy

It was two days later that I had a bit of a lightbulb moment, reproduced the situation and just for fun tried this:

    $ git -c core.bare=false config --unset core.bare

I didn't expect, but it worked!  Great.

Some thoughts:

    1) Perhaps 'git config' should be more careful in the first place
       and refuse to set 'core.worktree' when 'core.bare' is already
       true and vice versa.

    2) The damage was done with 'git config', so I expected that I can
       repair it with "plain" 'git config' (i.e. without 'git -c') as
       well.  'git config' has nothing to do with the path to the
       worktree after all.  And 'git config --edit' should work
       regardless of the mess that might be in the config file.

    3) 'git help <cmd>' should always work, shouldn't it?  (Though
       that's the easiest to remedy, just cd out of the repo, or fire
       up a new terminal window.)

Gábor

On Wed, May 27, 2015 at 12:31:47PM +0200, SZEDER Gábor wrote:

Right now git-config doesn't know anything about the meaning of the config variables; that logic is spread throughout the code, at the actual users of the variables. So I'm a little hesitant to special-case this one problem (especially because I think we can fix this in a different way).

The problem is that setup_git_directory is overly eager to die in this case (even when we use the "gentle" form to indicate we can handle being outside of a repo). Patch is below.

It looks in the repo (gently) so that it can find repo-specific config like help.format. And thus gets caught in the same problem as git-config.

-- >8 --
Subject: setup_git_directory: delay core.bare/core.worktree errors

If both core.bare and core.worktree are set, we complain about the bogus config and die. Dying is good, because it avoids commands running and doing damage in a potentially incorrect setup. But dying _there_ is bad, because it means that commands which do not even care about the work tree cannot run. This can make repairing the situation harder:

  [setup]
  $ git config core.bare true
  $ git config core.worktree /some/path

  [OK, expected.]
  $ git status
  fatal: core.bare and core.worktree do not make sense

  [Hrm...]
  $ git config --unset core.worktree
  fatal: core.bare and core.worktree do not make sense

  [Nope...]
  $ git config --edit
  fatal: core.bare and core.worktree do not make sense

  [Gaaah.]
  $ git help config
  fatal: core.bare and core.worktree do not make sense

Instead, let's issue a warning about the bogus config when we notice it (i.e., for all commands), but only die when the command tries to use the work tree (by calling setup_work_tree). So we now get:

  $ git status
  warning: core.bare and core.worktree do not make sense
  fatal: unable to set up work tree using invalid config

  $ git config --unset core.worktree
  warning: core.bare and core.worktree do not make sense

We have to update t1510 to accomodate this; it uses symbolic-ref to check whether the configuration works or not, but of course that command does not use the working tree. Instead, we switch it to use `git status`, as it requires a work-tree, does not need any special setup, and is read-only (so a failure will not adversely affect further tests).

In addition, we add a new test that checks the desired behavior (i.e., that running "git config" with the bogus config does in fact work).

Reported-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
---
The message for "git status" is a little clunky (first we warn, then we
say "wait, that warning was important!"). I also considered dropping the
warning (so you'd see nothing in the "git config" case) and then just
moving the die() to setup_work_tree().

 setup.c               | 12 ++++++++++--
 t/t1510-repo-setup.sh | 24 ++++++++++++++++--------
 2 files changed, 26 insertions(+), 10 deletions(-)