Re: Confusing error message due to Git trusting is_bare_repository()

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2011, 17:57 UTC
Message-ID: <7vwrjn5bhd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTi=9CpMU9aZs2zuvRyv3rpECkRAvYA0Srnc61whg@mail.gmail.com>

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

Show 23 quoted lines

> 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.

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.