9

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?

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
bambo Growth
  • 135
  • 1
  • 10

4 Answers4

6

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.

Drew Noakes
  • 300,895
  • 165
  • 679
  • 742
  • 1
    I wonder whether `git checkout HEAD` would have worked, instead of creating a new branch first. (I just had to do that, because of some MinGW weirdness.) – jpaugh Apr 08 '18 at 21:33
  • I was on `master` when I had the problem, and tried `git checkout master`, but it didn't like the fact the workspace has uncommitted files. Would `HEAD` be different to `master` if that's what I have checked out? Aren't they the same? In my case I couldn't reset the files. In the end, adding them and committing works to clear the workspace, then I could carry on as usual. Haven't had any problems since thankfully. – Drew Noakes Apr 09 '18 at 00:31
  • There shouldn't be any functional difference there, since `HEAD` and `master` point to the same commit. What I should have said is `git checkout HEAD -- .`, since that would allow overwriting changes (I think). In any case, I have sporadic problems with the filesystem under MinGW, so I'll keep this seemingly superfluous cmd sequence in my bag of tricks. Thanks! – jpaugh Apr 09 '18 at 13:18
  • One of the dirty hacks I still use til today and haven't found a better alternative. Is there really no better way to just discard everything I just did? Why do I need to commit my wrong changes first in a trashcan branch, checkout to master and delete the trash. Concretely, is there a better/intended way? – AgentM Apr 23 '20 at 21:57
3

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)?

torek
  • 448,244
  • 59
  • 642
  • 775
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.

joesdiner
  • 1,125
  • 9
  • 11
1

In my case, I had a file named con.sh in my repo, and I was trying to check out this repo on a windows computer. con is the name of an I/O device on windows command line, and any file or folder that starts with con conflicts with this device reference. This looks like a bug in both git and windows.

I deleted the local repo folder. Then, I renamed con.sh to connect.sh on a mac and cloned the repo again on windows.

Daniel Ladner
  • 11
  • 1
  • wow that's bizarre. On windows, in a newly made repo, trying to `git add` a file named con.sh is an infinite operation. Similarly `git mv foo con.sh` incorrectly states the file already exists. – TamaMcGlinn Aug 11 '20 at 04:55
  • 1
    Yeah, con is the console device "file", so git add is waiting for input from the console. git mv is probably seeing that con I/O "file" exists and is refusing to move it. I would prefer git just skip checking out files that error instead of corrupting the repo state. I would prefer windows not let con.sh conflict with con and/or move con to a root folder like linux's /dev/stdin. – Daniel Ladner Aug 11 '20 at 14:34