"git reset --hard " error unable to stat just-written files after setting "core.bare" to false

Question

When I try the following bash commands:

git clone --bare https://github.com/planetoftheweb/learnangular.git .git
git config --bool core.bare false

followed by:

git reset --hard 

it gives me this error :

error: `unable to stat just-written` file app/component.app.ts: No such file or directory
error: unable to stat just-written file app/component.artist-details.ts: No such file or directory
error: unable to stat just-written file app/component.artist-item.ts: No such file or directory
error: unable to stat just-written file app/pipe.search.ts: No such file or directory
error: unable to stat just-written file app/app.modules.ts: No such file or directory

what is the reason?

Answer 1

For others who land here because of the title, but aren't using a bare repo, the following might help. I was in a weird state where I couldn't reset --hard due to error:

error: unable to stat just-written file...

I couldn't checkout due to changes.

Here's what worked for me. Note that you'll lose any uncommitted changes. You might like to do a backup of the entire repo before continuing, just in case.

Delete all files and folders in the workspace except .git then do the following:

git checkout -b wat
git add .
git commit -m "WAT"
git checkout master
git branch -D wat

Basically this creates a commit on a branch called wat that marks every file in the repo as deleted. We then have a clear workspace and can checkout master again and delete the useless branch wat.

I've just done this and will be keeping an eye on the repo for any further weirdness, and pushing any unpushed branches elsewhere for safety.

Hope this helps someone out one day.

Answer 2

git clone --bare makes a bare clone.

git config --bool core.bare false tells Git that the bare clone is not a bare clone. But it still is. As we used to say about compilers, if you lie to Git, Git will get its revenge.

If you don't want a bare clone, the simplest method is to not add --bare to your git clone command. If you are dead-set on converting a bare clone to non-bare, see How do I convert a bare git repository into a normal one (in-place)?

Answer 3

For others who land here because of the title, but aren't using a bare repo and don't have Drew Noakes's issue, the following might help. For me the problem was I cloned a repo in Windows using TortoiseGit that had a filename with a trailing space at the end, example.png (<-- there is an extra space after the 'g') instead of example.png. I don't think TortoiseGit and/or Windows itself and/or NTFS can handle the trailing space properly. I don't think command line git likes it under Windows either, but I did not investigate that much. In my case the file was not supposed to have the trailing space anyway, so the following git commands in Windows fixed the situation:

git mv -f "example.png " example.png
git commit -m "Removed trailing space from filename"

I think the file was originally committed under Linux, which apparently does not get as confused with the trailing space.