Git: remote: fatal: index file corrupt, "index uses yz extension"? - wordpress

I have just encountered an issue I have never seen before and can't find any help on.
I run a git master repo on the live website in our hosting environment, and a bare origin repo on the same server. All our developer commits go to the bare origin master, which has a post-receive hook to push each commit to the master repo so that the push is reflected in the live site files. The only annoyance is that whenever we get WordPress updates, we have to commit on the master repo, then push it back to the origin repo so that our developers can download those updated files.
Problem: Today, I went to commit a WordPress plugin update, and the commit worked fine, but the push gave the following cryptic error that I cannot find any help on:
git push origin master
Counting objects: 344, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (344/344), 1.76 MiB | 5.61 MiB/s, done.
Total 344 (delta 237), reused 14 (delta 1)
remote: Resolving deltas: 100% (237/237), completed with 226 local objects.
remote: Running post-receive (git pull origin master):
remote: error: index uses ▒yz▒ extension, which we do not understand
remote: fatal: index file corrupt
(The weird symbols around the letters "yz" reads as "<B3>yz<AC>" when I run git diff)
If I run git status on master (cannot be run on origin as it is a bare repo), it repeats the last two lines of output. If I run git log on both repos, they look normal, but the origin is of course one commit behind the master, because committing to master worked, but pushing to origin failed.
I have never heard of this "yz" extension before, and as far as I can tell, no one else has either. All I did was a commit and a push and the push failed. We do not use any such "yz" extension, we use vanilla Git, do very basic pushes and pulls, our post-receive hook is about a 5 line script which just auto-pushes every commit from origin to master and resets file permissions to ensure they're readable by the web server. The only weird thing we're doing is using Git to manage a WordPress site for version control. All developers use TortoiseGit on Windows without any special settings or any sort of plugins.
I have seen plenty of questions and answers about corrupt indexes, but nothing like this.
I have not tried anything yet as I'm not sure what to do, don't understand the internals of Git, and don't want to break anything, but we need to be able to pull and push and cannot until the repos are in sync again.

Everything prefixed with remote: came not from your Git but from their Git—the Git your Git called up, at the URL you used when you ran git push.
It's their Git that is complaining about their Git's index. This is probably a file corruption issue on their machine. You need to get them—whoever "they" are—to check out their system. If all looks OK, they should probably just remove and rebuild their index files.
(If "they" / "them" is really you, go over to whichever machine(s) are involved, inspect them carefully for damage or disks that are on fire or whatever, and if all looks good, remove and rebuild the index files.)

Alright, here's what I did:
Because I did not want to lose any changes to the master repo (corrupt index), as the changes needed to be kept and also pushed to origin (working index), I ran the following:
rm .git/index
git reset --mixed
(mixed is the default option)
According to the documentation:
--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
Thanks to torek and bk2204 for your help in understanding the situation, and a little bit of googling to figure out the safest process for resetting an index without losing any committed or working files

Related

Azure Git Deploy Doesn't Include More Recent Commits

I am deploying a .net application to Azure via a git deployment. However when I launch the deployment I can see it spinning on the website and eventually complete, however it has an older commit message listed and not the most recent commits. I also confirmed in /site/deployments/ that it is using an older commit ID. What would possibly cause the deploy to appear as thought it works but essentially ignore a bunch of commits after a certain point? I also confirmed in the code that it isn't getting updated.
It looks like it is just taking the commit on top (the one deployed a few weeks back) and updating the date of it to be today.
UPDATE: I will also say that this branch was initially an autodeploy and it was failing for permissions for some reason. I have a bunch of instances that have a similar code base and set up and all of them work. Not sure if the fact it was an autodeploy at first is making a difference but why would pushing directly to the remote's master look like it is working but not include updates?
UPDATE 2:
Here are photos of the progression: There is definitely commits after the one it keeps reusing that I cherry-picked from other branches.

Git: how to re-push changes already pushed, but lost due to re-creation of staging version

We use WPEngine to host WordPress sites and push changes via Git to a staging version of the site - these can then be deployed to the production version via an internal script.
We staged the live site a few days ago and pushed up a number of changes via Git to the staged version.
Accidentally, one user pushed the button to recreate the staged version of the site and all our changes were lost - Git thinks that the local and remote are up-to-date - but of course, the staged version now shows the files in the form they are on the current live site.
Is there a way that we can force push up commits from the last x days or between two set hashes - or some other correct way to notify Git that the changes are no longer in sync?
Thanks!
git push <remotename> <commit SHA>:<remotebranchname> should do the trick, provided <remotebranchname> already exists on the remote. If it doesn't, use git push <remotename> <commit SHA>:refs/heads/<remotebranchname>
Note that this pushes all commits up to and including the commit you choose. If you don't want that to happen, you should first use git rebase -i to re-order the commits.
Note: Picked this from thread on SO : git - pushing specific commit. Check it out for more details.
I have had a similar issue when I have had to restore a site from a backup on WP Engine. What works for me is to just change something in a file.
Add a return at the end of any tracked file (any change at all will do)
Commit change
git push to remote
This should make sure everything matches local, adding/deleting/changing where needed, not just the last commit.

Trouble pushing Git Sub Modules to server- Using Post Receive hook.

I've spent a few weeks on this one, and I'm finally giving in and asking for help. I think I've tried just about every method I've seen suggested in other posts and tutorials, however nothing seems to be working. Anyways, here is my setup-
I have a git repository stored on BitBucket that is my local repo. I want to push my changes to my remote production server (and also staging), but for now lets focus on making one work. The way I have the remote server set up is by using a post-receive hook outside of my public_html folder. The folder is called repos and the bare repo is called development.git. The post receive hook inside repos/development.git is simple enough-
#!/bin/sh
GIT_WORK_TREE=/home/peterj05/public_html git checkout -f
I added the production server as a remote inside my local repo as "production" and push to /myserversaddress/repos/development.git, and the post-receive hook then transfers it to my public_html folder where I want it. The problem is that I have Wordpress added as a submodule and that the submodule does not get pushed along with everything else.
I've tried adding
git submodule init
git submodule update
to no avail.I've also tried some other methods, but either I'm screwing things up (which is entirely possible. While I'm not new to Git, I'm no expert by any means, and sometimes need things spelled out for me). Deployment options especially are new to me, which is why a lot of this has been so hard.
I'm willing to try just about any method, other than the pay service deployment options out there.
I'm at the end of my rope here. I've read so much and nothing seems to be working. I have to be missing something here. I am also pushing recursively in case anyone is wondering.
-P.J.

local dir replace, incoming dir edit upon update?

I have a conflict and I am unsure how to resolve it.
The error I get when doing svn udpate is:
Tree conflict on 'wp-content/plugins/eventON'
> local dir replace, incoming dir edit upon update
Select: (mc) keep affected local moves,
(r) mark resolved (breaks moves), (p) postpone,
(q) quit resolution, (h) help:
I do not understand what this is trying to tell me.
I would like it to replace the local version of the web server's plugins/eventON with the version that is in the SVN repo.
Background info:
The error message may be the result of deleting the folder that was being versioned through Wordpress admin panel, and then copying another one in the same location (a bad attempt at updating a plugin while forgetting how SVN works).
I guess that running the update through Wordpress deleted the .svn folders that were present in the plugin (the needed stuff for SVN to work properly).
So you could delete the new, unversioned eventON folder that you have copied in your repo, and run a svn update from one directory above (wp-content/plugins), in order to retrieve the old, versioned plugin.
If it does not work, it may be easier to delete the repository and checkout a fresh version...
Then, you will be able to update your plugin manually through SVN, and commit it.
As long as you already know that you want the server's version and not the local, this shouldn't be too difficult to resolve.
Identify which files are conflicted with svn status.
Since you want to keep the repository's version, you probably want to remove any conflicted files that svn has added from your working copy. They will have an A next to them in the output of svn status. In your case you should probably back them up first, since svn can't get them back for you since they're not in the repo yet. Now use svn delete --force my/fileToDelete. You don't need to delete anything not related to the tree conflict if you have made other changes you want to keep.
Run svn resolve --accept=working my/treeConflictFolder on the remaining folder that is conflicted (it will have a capital C next to it in the output of svn status)
The tree conflict should now be resolved, so you should be able to commit and update normally.
Further reading: http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html

Aptana synchronising remote changes

I have Aptana Studio 3 set up using the Deployment Wizard to sync changes in both directions from local/remote for my projects. This works fine for syncing local changes to the remote site; my changes get FTP'd up automatically.
It doesn't seem to be working out when a file has changed remotely - there have been several situations where I've opened a file that has been modified by someone else since I last downloaded it, and the remote changes have not been downloaded to my local copy.
I've been manually synchronising directories before starting to work on them but this is a bit of an annoying workaround. Is it possible for Aptana to automatically check for remote changes, and sync my local copy?
I found a bug report which pretty much answers my own question: https://jira.appcelerator.org/browse/APSTUD-2811
Unfortunately it doesn't look like this is going to be fixed any time soon. It's a pretty essential feature IMO, especially for those working in teams.
You should consider using Git for moving files around (plus the whole version saving feature).
If you make a change on your local development system, simply
$ git add .
$ git commit -m "made a change"
$ git push origin
And then pull it down on your deployment server.
$ git pull
All done.
If you make a change on your deployment server, simply commit that change on the deployment server, and subsequently pull that change down to your development machine. There isn't really that much of a need for FTP anymore, although it does come in handy for moving untracked binary files.
http://try.github.com/levels/1/challenges/1

Resources