Cannot add any file to GIT "libgit2 returned: Invalid data in index - invalid entry"
Cannot add any new file to GIT repo :-( "libgit2 returned: Invalid data in index - invalid entry" Have recently locally committed changes to an existing Boost.Math sub-module (commit OK). (But realized that I had forgotten to add a few new files, so tried to add and recommit, but failed at the add stage). git status shows expected untracked files and ends: nothing added to commit but untracked files present (use "git add" to track) I:\modular-boost\libs\math> .gitignore is the standard modular-boost issue and looks OK. I:\modular-boost\libs\math>git version git version 1.9.5.msysgit.0 Suggestions? Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 25 Feb 2015 at 13:04, Paul A. Bristow wrote:
Cannot add any new file to GIT repo :-(
"libgit2 returned: Invalid data in index - invalid entry"
Yeah you've corrupted your index. Sometimes you can manually hand edit it back into life, but often it's easier just to zap it and recreate it. Obviously doing that will reset your repo, including working directory, back to last good commit. A safe alternative is to relocate the corrupted git checkout elsewhere, clone a new copy in its place, and manually copy over the changes. No chance of losing anything important that way. If the same corruption happens a second time, and if you are on Windows, I'd suggest wiping and reinstalling your all your gits. A few months ago I had a persistent git index corruption problem on Windows. git worked fine from mingw, but corrupted outside of mingw. I did a total purge of all git, msysgit, tortoisegit and mingw from the system, and reinstalling everything fresh. It fixed the problem, though it cost me a day of work. I think on Windows we get so many copies of git that sometimes the versions get mismatched, and this corruption appears. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas Sent: 25 February 2015 13:51 To: boost@lists.boost.org Subject: Re: [boost] Cannot add any file to GIT "libgit2 returned: Invalid data in index - invalid entry"
On 25 Feb 2015 at 13:04, Paul A. Bristow wrote:
Cannot add any new file to GIT repo :-(
"libgit2 returned: Invalid data in index - invalid entry"
Yeah you've corrupted your index.
Sometimes you can manually hand edit it back into life, but often it's easier just to zap it and recreate it. Obviously doing that will reset your repo, including working directory, back to last good commit.
A safe alternative is to relocate the corrupted git checkout elsewhere, clone a new copy in its
Gasp - that's not supposed to happen is it? What have I done wrong? I'm only using Windows 8.1 64-bit and I have one copy of git (driven by a mixture of Tortoise GIT and command line). How can I tell if a git is good and what is corrupt? My last commit didn't give any hints that all wasn't well. Should I be doing any regular checking? place, and
manually copy over the changes. No chance of losing anything important that way.
I have a backup and a zip of the files, but thousands of changes (to documentation).
If the same corruption happens a second time, and if you are on Windows, I'd suggest wiping and reinstalling your all your gits. A few months ago I had a persistent git index corruption problem on Windows. git worked fine from mingw, but corrupted outside of mingw. I did a total purge of all git, msysgit, tortoisegit and mingw from the system, and reinstalling everything fresh. It fixed the problem, though it cost me a day of work. I think on Windows we get so many copies of git that sometimes the versions get mismatched, and this corruption appears.
I'm not sure what you mean by 'copies of git' - do you so mean so many git repos, or ? But thanks for the bad news anyway ;-) Paul
On 25 Feb 2015 at 14:09, Paul A. Bristow wrote:
Cannot add any new file to GIT repo :-(
"libgit2 returned: Invalid data in index - invalid entry"
Yeah you've corrupted your index.
Gasp - that's not supposed to happen is it?
You'd be surprised at its frequency under certain use cases, even on Linux.
What have I done wrong?
Linus intended the index originally as a cache, so he didn't go out of his way to make it robust. I think that, with hindsight, was a mistake. Forthcoming TripleGit doesn't make that mistake incidentally. However the index is very much disposable, if inconvenient. Deleting it won't lose you much data, just what you have changed between now and the last commit. And it can always be regenerated from the last commit made to the backing object store.
I'm only using Windows 8.1 64-bit and I have one copy of git (driven by a mixture of Tortoise GIT and command line).
Ah, but that install actually has three git instances! There is one git in msysgit, another in TortoiseGit, plus TortoiseGit keeps another copy of libgit inside itself. If you install any mingw or cygwin, you get another git. If you install Visual Studio, yet another git comes into play. Most tools just call 'git' and whichever on PATH or the current directory catches it first gets called. The fact it works at all without data loss is amazing.
How can I tell if a git is good and what is corrupt? My last commit didn't give any hints that all wasn't well.
Should I be doing any regular checking?
No, you just roll with the punches. As I mentioned, losing the index really isn't important. Your repo and everything you have committed is safe. You may just lose a bit of work since the last commit, that's all. As I mentioned, occasionally deleting all traces of git and reinstalling on Windows is a very good idea. Syncs up the versions to a single version you see, and cleans up PATH so hopefully only one git is called.
Sometimes you can manually hand edit it back into life, but often it's easier just to zap it and recreate it. Obviously doing that will reset your repo, including working directory, back to last good commit.
A safe alternative is to relocate the corrupted git checkout elsewhere, clone a new copy in its place, and manually copy over the changes. No chance of losing anything important that way.
I have a backup and a zip of the files, but thousands of changes (to documentation).
None of these changes were committed? If they were, you have lost nothing. If you didn't, you'll need to manually copy over the changed files by hand (a bit of robocopy or rsync magic can do this for you into a new fresh git clone, have it copy if modified).
If the same corruption happens a second time, and if you are on Windows, I'd suggest wiping and reinstalling your all your gits. A few months ago I had a persistent git index corruption problem on Windows. git worked fine from mingw, but corrupted outside of mingw. I did a total purge of all git, msysgit, tortoisegit and mingw from the system, and reinstalling everything fresh. It fixed the problem, though it cost me a day of work. I think on Windows we get so many copies of git that sometimes the versions get mismatched, and this corruption appears.
I'm not sure what you mean by 'copies of git' - do you so mean so many git repos, or ?
But thanks for the bad news anyway ;-)
It's not bad news, more a consequence of how git has been implemented on Windows. Due to the lack of a package manager, everything has to bundle a git. Sometimes one git doesn't like another git for some reason, and the index gets eaten. Remember also that Windows has very different open handle semantics to POSIX. In particular, if one git tries to delete an index while another git is working with it, the deletion request returns an error on Windows. The error handling for that should be much better tested than it is, but in the end it is extremely unlikely for unlink() to ever fail on POSIX, so it isn't a debugging priority there. The Windows port shows the consequences of that. Really what Windows needs is a ground up native reimplementation of git. All these problems go away then. Problem is who would fund such a thing? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Niall Douglas -
Paul A. Bristow