CODEWITHSUNDEEP
gitvisual-studiogithubgit-commit
Vuqar Rahimli
Vuqar Rahimli

Reputation: 11

Fatal error when committing changes to git from visual studio

So everything was working fine, until yesterday I wrote some code and pushed, but nothing changed in GitHub, so I came and added a comment line and commited then it said fatal error :

Git failed with a fatal error. error: invalid object 100644 342bad3922f69c8ae111f019ceffc916dd4982cb for 'DataAccess/Concrete/EntityFramework/EfColorDal.cs' error: bad tree object HEAD

first the path was pointing to another class, I deleted and wrote it again, and when I committed again it showed this class this time, I figured it would just keep going. and when I run out of everything to try from internet, I decided to restart, upon opening again it said Fixing errors in D disk, where is my solution is placed. It was fixing for like an hour, when it finally ended, nothing changed.

I used gitbash console to execute the codes when I run codes like git --fsck it said:

Checking object directories: 100% (256/256), done.

notice: HEAD points to an unborn branch (master)

notice: No default references

missing tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904

As I dont know anything about git coding, I tried some more stuff previous posts suggested, but none of it worked. My local repository is in C disk and it holds the code before yesterday, so I could write the code again, but there is no guarantee it wont happen again, so Im open to any help offered. Thanks

Upvotes: 0

Views: 1099

Answers (1)

torek
torek

Reputation: 487993

upon opening again it said Fixing errors in D disk

What "it" is this? I presume "it" was your operating system.

It was fixing for like an hour, when it finally ended, nothing changed.

I think several things had changed at this point. When your OS tries to "fix" problems on a file system due to unexpected power failures, or disk errors, or other hardware problems, one of the things your OS will do is remove various files. Essentially, the OS discovers that while some file was created (so that it appears to be valid), it was never finished (so it actually isn't valid). The OS's solution to this problem is to remove the file.

Meanwhile, Git itself is extremely sensitive to certain file-removals. Several after-crash removals are common, and each one breaks Git in a specific way. The git fsck command checks for this kind of damage (among others):

  • Removal of a file containing branch data can produce messages such as notice: HEAD points to an unborn branch (master).

  • Removal of a file containing an internal tree or blob object can produce messages about missing tree and/or blob objects.

These are the two messages that your Git has produced here, so we can conclude that something damaged, perhaps irrecoverably, the repository on the D: drive.

My local repository is in C disk and it holds the code before yesterday ...

The GitHub copies of the repository will probably also be intact, and will be as up-to-date as you made them. That's why (or perhaps a better adverb is how) Git, as a distributed system, is pretty resilient: even if multiple copies of the repository are destroyed, other copies remain fine.

so I could write the code again, but there is no guarantee it wont happen again ...

Indeed. What is it about the D: drive that caused it to become damaged to the point that the Git repository did not work and the OS decided to repair it? Git is not the issue here. Rather, the D: drive is.

Upvotes: 1

Related Questions