Confusing error message due to Git trusting is_bare_repository()

I had a co-worker git this well-known error message:

    error: refusing to update checked out branch: refs/heads/master
    error: By default, updating the current branch in a non-bare repository
    error: is denied, because it will make the index and work tree inconsistent
    error: with what you pushed, and will require 'git reset --hard' to match
    error: the work tree to HEAD.

It *was* a bare repo, but the config file had bare=false because someone had simply copied a .git tree from a non-bare repo to make it.

The issue is that we just use this:

    int is_bare_repository(void)
    {
        /* if core.bare is not 'false', let's see if there is a work tree */
        return is_bare_repository_cfg && !get_git_work_tree();
    }

For the purposes of the error message it would be helpful if we also detected whether something didn't have a working tree, but was set to bare=false, and tell the user to updatet he bare=false to bare=true for his almost-bare repository.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

The only reason we have it as a config variable is because there isn't a way to make that determination.

How would you propose to detect that?

As a trivial and obvious example, is the result "git clone -n" a bare repository?

Note that it is a perfectly valid workflow to:

	$ git clone -n github.com:gitster/git.git temp
        $ cd temp ;# no checkout, but is .git/ in it a bare repository?
        $ git read-tree origin/master ;# now with the index, but no checkout
        $ git merge origin/jc/diff-dotdot
	$ git show -m --first-parent

to make a merge with minimum number of paths checked out in a temporary repository that should still be considered non-bare.

Of course, you cannot base the determination on "do we see $GIT_DIR/index file there?" Most likely people who renamed foo/.git to foo.git and then removed foo directory didn't bother to remove foo.git/index.

On Fri, Mar 25, 2011 at 11:56:20AM +0100, Ævar Arnfjörð Bjarmason wrote:

That seems like the problem there. I'm not blaming the user; what they expected to happen is reasonable, and even used to work. But I wonder if better education is possible.

How do we know whether or not it has a working tree? Can't I do something like:

  cd /var/working-trees/foo
  git init
  mv .git /var/repositories/foo.git
  export GIT_DIR=/var/repositories/foo.git
  echo content >file && git add file && git commit -m foo

I thought the reason that core.bare was introduced was to handle weird cases like this.

-Peff