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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html