Cute new note-git problem (error: object file. git/objects/* is empty...) solution and understanding of git version library files, gitobjects file is too large

Cute new note-git problem (error: object file. git/objects/* is empty...) solution and understanding of git version library files, gitobjects file is too large

Due to improper operations, a major problem occurs in the git version library, as shown below:

error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is emptyfatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

 

The system prompts that the xx file is empty. This error occurs when you use commands such as git log, git commit, and git status (file names may be different ). If you delete. git and re-init, it will easily and violently solve this problem. However, the previous version information is lost, which is not the expected result. So I plan to fix it.

 

First, paste the link to the correct solution found: http://stackoverflow.com/questions/11706215/how-to-fix-git-error-object-file-is-empty

If you cannot understand it, there will be a simple version.

 

Then, let's talk about my own practices:

 

At that time, I thought that since it prompts that there was a problem with the file, what would happen if I deleted it? The result is that the other file is blank. That is to say, you have to delete it. What happens if I modify its log? So, the log file I checked is:

cd .gitcd logsvim HEAD

 

I found that the log file is preceded by the version information I submitted earlier, but the last line is garbled. So I deleted the garbled lines. At the same time, cd is added to a sub-directory under another current directory.

cd refscd headsvim master

 

Delete the garbled characters in the last line.

 

Then, I found that refs, another subdirectory of. git, stores something that seems to be the current version. refer to the previous HEAD file and change it to a normal version number. Now, I use git log to display logs normally! Then I tried to add it and found OK, without prompting anything. It is said that no prompt is a good thing. However, what I never expected was that at the time of commit, I started to prompt that the xx file was empty.

 

It seems that I made a mistake.

Although I was not successful, I seem to have a little understanding of the file structure of the git version Library:

[ccx@ubuntu ~/miniSearchEngin]$>cd .git/[ccx@ubuntu ~/miniSearchEngin/.git]$>lbranches/  COMMIT_EDITMSG  config  description  HEAD  hooks/  index  info/  logs/  objects/  refs/

 

One by one, branches is an empty file (mine is). "branches" means files related to branches. I haven't used branches yet, not very clear.

COMMIT_EDITMSG, which indicates the editing information when the file name is probably guessed as commit. The result is the same as the guess:

[Ccx @ ubuntu ~ /MiniSearchEngin/. git] $> cat COMMIT_EDITMSG: The Lenovo function of the dictionary is OK, and multi-threaded services can be visually tested.

Echo with the last line of the log file:

31 e5085f07d6f8578bad1ae39d85bf88db6886c51d bd9a33f13603ef3b53184e3b9ce9408638b71fb4 ccx19930930 <461661280@qq.com>
1480909458 + 0800 commit: The dictionary Lenovo function is OK, and multi-threaded services can be visually tested.

 

Then there is the description file. Well, I don't know what it is for. (I will omit it and I don't know it. I will try again later)

　　

HEAD, which is a file path:

[ccx@ubuntu ~/miniSearchEngin/.git]$>cat HEADref: refs/heads/master

[ccx@ubuntu ~/miniSearchEngin/.git]$>cat refs/heads/masterbd9a33f13603ef3b53184e3b9ce9408638b71fb4

The file content is the same as the last large number in the log file. So I guess it may be the current version.

 

What if I delete the HEAD or change the path in it:

Deletion:

[ccx@ubuntu ~/miniSearchEngin/.git]$>mv HEAD HEAD.h[ccx@ubuntu ~/miniSearchEngin/.git]$>cd ..[ccx@ubuntu ~/miniSearchEngin]$>git logfatal: Not a git repository (or any of the parent directories): .git

Changed:

[ccx@ubuntu ~/miniSearchEngin]$>git log fatal: Not a git repository (or any of the parent directories): .git

The system prompts that no git version library is available.

 

If you manually change refs/heads/master to a previous version number, the previous log information will be displayed during git log. It is like a log file, but the file is still unchanged. If I use git status after this operation, a bunch of uncommitted red files will be displayed. You can also perform add and commit operations. View the log file and you will find new information added to the last line. You may wish to name this operation.

Here we will talk about the log file. The screenshot part is as follows:

1 0000000000000000000000000000000000000000 commit ccx19930930 <461661280@qq.com> 1480061835 + 0800 commit (initial): build git 2 commit ccx19930930 <461661280@qq.com> 1480082783 + 0800 commit: Word Frequency Statistics for Chinese and English words, does not contain full, halfwidth punctuation 3 Gbit/s ccx19930930 <461661280@qq.com> 1480128209 + 0800 commit: deprecated WORD 4 Gbit/s ccx19930930 <461661280@qq.com> 1480176053 + 0800 commit: group OK

The first two digits are like the start and end of the previous row. Since the current version number is stored in refs/heads/master, I am very happy to regard it as a linked list, with the current version as the linked list of the header node:

+ ========================================= +
| Current version | --> | previous version | -->... --> | second version | --> | first version |
+ ========================================= +

After operation:

+ = + + =======+
| Current version | -- + | version before operation A | -->... +-> | version set in operation A | -->... --> | first version |
+ =======+ | + ===================+ | + ============ ==++ =========+
|
+ ------------------------------- +

That's all.

 

In the objects folder, files of different versions should be stored. The files may have been encrypted or implemented by different algorithms. If they are opened, they are messy and do not know what to write.

As mentioned before, the logs folder stores log files.

The refs folder stores the current version information, "head node of the linked list ".

 

Well, it's been so long since the force (sell) went back to the topic.

Finally, I used the method in the first link to solve the problem:

 

At the very beginning, back up the. git folder first. What if it breaks down?

 

First, delete all blank files:

cd .gitfind . -type f -empty -delete -print

 

Then, print the last two lines of the log file:

tail -n 2 .git/logs/refs/heads/master

 

Check whether the xx version is normal, that is, the first one printed in the previous step.

Git show xxxx (Version)

 

After that, go back to the file:

Git update-ref HEAD xxxx (Version)

 

Check:

git fsck

 

I can use it now, and there is some processing behind the link. I have not continued to do it (I am a little lazy, just to fix the version library, now that I can use it, I will not proceed. What if it breaks down again)

 

Remaining operations in the link:

rm .git/indexgit resetgit fsck

However, when I wrote this article, I found that the great god was useless after doing so. He also said that he didn't want to continue with the work, probably it might mean this.) I will use it --!

 

Finally, I looked at the repaired log information and found that it is equivalent to the "delete node in the linked list" operation. The error log information is still garbled. I also don't want to delete it, so I am afraid that I will delete it again.

 

Postscript:

At the time of writing this article, I had fixed the git version library for more than a week, and the backup error Library had already been deleted (permanently deleted. I just cleared the recycle bin a few days ago --!), Some of them may not be clearly described. Sorry.