About one month about I've created bare git repository.
And over last month I've been committing my source changes from eclipse to that repository over SSH.
The problem occurred today, when I tried to commit and push updates from eclipse. Here is whole error I've got:
Repository ssh://dany#192.168.0.18:22/home/dany/git/SVP2/
missing necessary objects
error: object file ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0 is empty
error: object file ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0 is empty
fatal: loose object 60916b83370c1535a4be9924e71e9954c01e82e0 (stored in ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0) is corrupt
error: object file ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0 is empty
error: object file ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0 is empty
fatal: loose object 60916b83370c1535a4be9924e71e9954c01e82e0 (stored in ./objects/60/916b83370c1535a4be9924e71e9954c01e82e0) is corrupt
I can assume what is wrong, but I dont know how to solve it.
I think it may be related to the error on linux server where that repository is:
Read-only file system
I don't know why and when my system switched to read only mode.
I'have back ups:
source code in my local machine in eclipse project, wich is also local git repository
git bundle file of this git repository
Can they be use to restore repository to working one?
Please help. I am frightened.
I am quite new to git. I don't have any team member to ask for this. Please help.
-------------- Edit ---------------------
Thanks to: #codeWizard
On Remote bare repository
dany#192.168.0.18:~/git/SVP2$ git fsck --full
error: object file ./objects/06/b08928836077489d0ede51a0af42c7807b1943 is empty
error: object file ./objects/06/b08928836077489d0ede51a0af42c7807b1943 is empty
fatal: loose object 06b08928836077489d0ede51a0af42c7807b1943 (stored in ./objects/06/b08928836077489d0ede51a0af42c7807b1943) is corrupt
korbeldaniel#192.168.0.18:~/git/SVP2$
On Local working repository
dany#dany1l:~/git/SVP2$ git fsck --full
Checking object directories: 100% (256/256), done.
dany#dany1l:~/git/SVP2$
As you can see its all about the same object.
Verify that the repository is in a "good" state:
git fsck --full
It will verify that all the files in your repository are in a "good" state.
In case of errors to any of the files it will display that a given hash is not good which means that if the file is in the list and its not a dangling state the checksum (SHA1) does not match the content.
It this case the file is corrupted.
If the file not corrupted
If you want to verify that the problem is not in your current branch, checkout last working master, create new branch form it and try to push the new branch.
If the push is working so you have verified that the problem is in one of your repository files.
I had normal dir and file backup of git repository in zip archive, which I used to restore, fix error.
~/git rename to ~/git_old_corrupted
unzip git folders and files structured backup into ~/git
commit and push to remote repository (one which was earlier corrupted)
This commit have pushed my all earlier commits at once.
Now it is back to normal again.
Related
I recently updated the development server that hosts our code repos to a newer version of Ubuntu (18.04). As part of the process git was upgraded to version 2.23.0. The actual application servers where the code gets deployed to need to be able to checkout the latest changes from the git repos. When I try to do a 'git fetch' on those servers I get a long list of errors that look like this:
error: index file
./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx is
too small
I did some digging around to see if I could come up with a solution but so far noting has worked. I tried the answers listed here: git error: "index file is too small" .
Neither git index-pack nor git repack -a -d solved the issue. I even tried deleting the local copy of the files from the application server and installing fresh using git clone. The clone itself threw a bunch of errors similar to before
remote: error: index file
./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx is
too small
At this point I'm out of ideas. Any help would be appreciated.
Edit: The output of du -h suggests that there is enough disk space.
The error message sounds like file corruption. If you have not run out of disk space, you can delete the index file and recreate it with:
git index-pack -v ./objects/pack/._pack-5b58f700fea57ee6f8ff29514a376b945bb1c8a9.idx
You might also want to run use git-fsck to
verify the connectivity and validity of the objects in the GIT database -- both the remote the local one.
If your index is corrupt, you can also try to reset the branch which will create a new index file:
To be safe, backup .git/index.
Remove the index file .git/index.
Perform git reset
References
The issue is a possible duplicate of git error: "index file is too small"
Documentation on git index-pack can be found at https://git-scm.com/docs/git-index-pack
Some notes on repairing a broken index: https://makandracards.com/makandra/5899-how-to-fix-a-corrupt-git-index
fatal: packfile name 'server' does not end with '.pack'
I encounter this error when transfer my git repo from Mac OS to another system. Files start with '._' are Mac OS meta files generated by tar command. So look at this question to avoid '._*' files: Tar command in mac os x adding "hidden" files, why?
So I created a file with a very long name (around 300 chars) to test something, but I no longer need it and have deleted it.. I did this in my svn repository. Then I cloned this svn repository into a git repository using git svn clone, which didn't give me any issue. However, the creation and deletion of this file is now recorded in my git commit history..
This is giving me issues when using git commands like filter-branch. Error is 'Filename too long cannot check out index'
I know the commit ids involving the particular file. Is there a way to get rid of these commits in the 'revision history' that will involve the file with the long name..?
Note: I performed the above on a Windows machine, but I tried moving to Linux machine and tried the filter branch command there as well but still getting the same 'filename too long issue'. I am new to Linux, so is there any setting that I missed out to handle long filenames?
Thanks in advance.
You should use git filter-branch with --index-filter so that you don't have to deal with filesystem limitations
I have cloned a GitHub repository into a new directory on my local machine using:
git clone git#github.com:*****/project.git destination-dir
Clone worked fine but whenever I try to pull or push I git this error back:
error: insufficient permission for adding an object to repository database .git/objects
fatal: git write-tree failed to write a tree
What have I done wrong? And how can I fix this. From what I read so far online, the problem is trivial if you are using your own repository (i.e. not GitHub) but what should I do if this on GitHub (there is no ssh access).
Also, I should add that I have another directory on my machine pointing to same repository on GitHub which is fine for pulls and push.
This doesn't look like related to GitHub per-se.
From what you say in the comments, it seems that the write permissions inside the hidden .git folder (which contains all of your local git repository data) were not corresponding to the permissions that your git client had when you ran it.
It can be that you cloned the repository with one user account (or using sudo), but where trying to pull/push from a different user. If that wasn't the case, something could have messed your local files permissions while cloning.
As you stated, doing chown -R login:group projectDir/ fixed the problem because it recursively reset all permissions in your project folder (including those of the .git folder and its contents).
A good experiment would be trying to clone the same repo to a different folder to see if the problem reoccurs. If it does, maybe something is wrong with your default permission usermask and/or your git client permissions.
I'm pushing to a remote git repo and I get the following on any newly created files
remote: error: git checkout-index: unable to create file
Changes to existing files are accepted, but this is obviously causing issues. Any ideas?
You see this problem when you use Git on a case-sensitive filesystem, then attempting to push changes to a case-insensitive one.
Make sure you aren't trying to commit FOO if foo is already in the repository.
I am new to use svn and the company in which I work uses three levels (I don't know whether this is a correct word to use here) of svn. I mean the developers are provided a working directory on a testing server. When we commit, it goes to the dev server. When a manager commits it from there it goes to production server. I am a developer here and one of my files is giving error (conflict) when I commit from directory. Not only, but also it gives conflict when manager tries to commit. I am now given access as manager too but I am still unable to resolve it.
What I've tried till now:
svn update
svn delete
svn commit
It gives conflict on all of these operations.
Earlier on a simple error happened and the manager preferred to just delete file on dev, copy it manually and then commit from there. I don't know this may be a reason of this problem or not.
Please help me resolve this issue. I've read some things in read-bean book too but to no avail yet.
Thanks
Ok, here's the update. The actual problem is that a file (ex lib/a.php) used to be in my working directory as well as in dev and production servers. Now it was deleted by someone (using del command, not svn delete) from dev server. Now question here is how I add it again so that it becomes part of svn again. The simple svn add doesn't work.
Update 2
From one of the answers below I understood that its a tree conflict. Some searching brought me to http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html . Following the instructions, I took the backup of the file and then svn delete it from everywhere. Then I svn add it to my directory, commit it and tried to update dev and production. End result is that it doesn't go there. No error is shown either.
svn info in my directory shows complete info of the file but on dev and production it shows
file_name: (Not a versioned resource)
:S
Any more ideas please?
Alternatively you can take backup of the file ,then say svn revert filename insert you new code.Do a svn up just to make sure you do not have any conflicts,and then commit
Or
fix the conflicts in the file and then you can say svn resolved filename and then you can continue operations on the file
Update:If your file is deleted using rm or del command use svn revert filename to get it back and you do not have to add it again.Just put in your new changes and say svn ci -m"your comments" filename
svn revert will fetch back the last checked in copy into SVN and it wouldnt have your any changes made before the user had used del command
Update 2:After u say svn delete ,u need to commit it until u get the message Deleting filename with a new revision number.Then add the file using svn add command,then commit again.Once this is done you can check the svn info, let me know..
Use svn status command to know the status of the file
The only problem apart from this i can think of is this the directory may not have been added.Is this a new directory?
ah, the old tree conflict problem.
The issue is that SVN is letting you know that you're adding a file that used to be there but it cannot tell whether you're trying to delete it, add it or just update it! So it does the only thing it can - flags a conflict so you can sort it out and fix it. Its basically a conflict on the directory level (rather than a conflict of a file's contents).
What you do is resolve the error (as others have pointed out), then update the directory to get the original file back, then commit your changes. Note that the file was never deleted from SVN - its still in the repo, and if you checkout out a new WC, you'd get the file.
Try to resolve the conflicts then commit again:
svn resolve --accept working