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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> writes:

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]