I'm in a lot of trouble.
During a composer update, somehow, the git process crashes and I have lost all my edits since last commit. It looks like there was an hard reset of my repository.
In eclipse I can find all the history files but I have to iterate on every file to check if it was changed and get the last version.
Unfortunately the massive "restore from local history" on the project doesn't work for edited file but only for deleted.
Is there any way to browse eclipse history and get all the last versions?
I know there are inside .metadata.plugins\org.eclipse.core.resources.history but they are hashed and probably I have many version of the same file.
Due to the poor documentation of XCodes files that manage your project under the hood, I cannot understand the purpose of the xcschememanagement.plist file, which is causing me a lot of problems.
Can anyone explain this file's purpose, and how we should be treating it with git source control?
Here is the full path to the file PROJECT_ROOT/xcuserdata/alecmather.xcuserdatad/xcschemes/xcschememanagement.plist
My problem with git and this file:
Let's say I start on branch_1.
I make some commits to this branch.
Then I switch to branch_2.
I make some commits there, and decide to run my project.
After I'm done, I stop running my project and switch back to branch_1.
I run my project there, and close it.
I attempt to switch back to branch_2 but am stopped by git saying that I have uncommitted changes in the current directory. But I did nothing but run my project.
So I'm assuming that this file holds some things that can get changed around when building/running your project? But this gets really tedious when switching between branches all the time. Do I commit the changes to that file from this scenario? Can I safely just discard the changes?
Yes, you can safely ignore the whole xcuserdata folder. All premade .gitignore files I've seen so far for Xcode projects do so, including https://github.com/github/gitignore/blob/master/Global/Xcode.gitignore
I "committed" my java project -or tried to. I only just downloaded egit for eclipse and was trying to configure it. I realized my project had not been uploaded so tried to delete what i did to start again.
I thought I was just deleting the commit but it deleted the whole project locally! It's not in my trash either.
Anyone any idea how to get it back?
Basically, if you didn't push the file to the remote repo and you deleted the entire project, then you have lost your local git repo. Check your recycle bin, or try to do a hard drive recovery, if you are lucky. Otherwise...S.O.L. Sorry :-(
I have: http://windows.github.com/
My current project has around 20k files, around 150MB (and not speaking about how slow it is and I cannot do a thing now) it doesn't even let me commit! I get this error: Commit failed: Failed to create a new commit.
That seems that nobody is having.
I've already deleted the folder and cloned again, no escape. What to do?
If I choose to open shell, all this *** crashes!
Edit:
Since the problem I've switched to Git Extensions and I didn't look back!
thanks for your answers
This happened to me. Try opening up PowerShell and manually committing each file using the "git add [file name]" command. To see which files have been added, enter "git status" into the command line. The green files have been added, the red ones have not been added.
Once you've added them all, type "git commit." Then go back to Github for Windows and sync it up.
I'm not sure what causes this issue, but once I followed the above steps, Github went back to its normal, awesome behavior.
I had this problem too after an unexpected crash. I couldn't fix using the 'Open Shell' option as suggested. I had to open the Windows CLI (Start -> run -> cmd) and delete the index.lock file in my GitHub folder:
cd \Users\myUser\my\local\github\repo
cd .git
del index.lock
Then when I went back to the GitHub app, it committed successfully.
Note that for some people, according to comments, the file to delete doesn't have the .lock extension, so the delete command could also be del index.
Im using Githug for Windows (7) and faced the same problem. While using PowerShell I realized that I didn't fill Full Name and email address in tools > options. Look like a beginner mistake (and I am!).
hope it helps!
just try to commit a few from your updates. 5 for example. and then make another commit with all other updates.
I am using windows client and getting the same error. Then suddenly I realized that my local db in app_data was opened on the SQL management. It just simply can't commit the some files to github if they are opened or using at the other programs.
Just disconnected management studio closed it and just simply committed.
This may be your case also. Check your files out!
So guys this is the full steps I had to take in order to fix the problem...
1) Using Process Explorer (you can download it form here http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) I searched for any process referencing ".git\index" and then I killed it.
2)Then using Git Shell (Windows Power Shell) I went into the repository which was giving me such difficulty and then furthermore went into its .git folder. (cd .\your_respository_name\.git). I then removed the index.lock file in that directory (rm -r index.lock).
3)Then from within that same directory I ran git reset HEAD.
4)Then I manually committed each file using the "git add [file_name]" comand. (You can check that they were added successfully if when you run git status, the files are green.
5)Next run git commit if your files are added correctly.
6)Finally go back to github for windows and sync everything up and it should hopefully work and resolve the problem.
This issue seems to be a bug in the github client - I get it "all the time" on the machine on which i only installed the github client.
I Never saw it on the git + github PC (I have not used it for a few days now).
Doing the "git add ." and then "git commit" worked for me also on the shell - but that is the thing the GUI should be doing not me - otherwise I can just stick to the git shell client.
Had the same problem, couldn't commit or sync using the windows GUI, but I could commit the changes through the shell. Once I'd added the changes through the shell the windows GUI started to sync normally. Hopefully it's a one off.
I had an interesting issue - even though I had an excel file open called "Combined - ForImportv4.xlsm", Git UI had no problem checking that in but it gave the error in the OP's subject for the backup file "~$Combined - ForImportv4.xlsm" so I discarded that change and all went through.
PS: As for why i'm checking an Excel file into Git ... just don't got there :)...
I had this issue with the git windows desktop commit tool. I was getting this often and I figured out that Visual Studios was locking the files. To get around this issue I simply closed visual studio and the commit / sync worked fine.
I googled failed to create repository and ended up here.
My problem was that the description for my new repo was too long. There is a charlimit for the description, but GitHub tried to push it anyway and failed.
I just had the same problem, tried some of the suggestions on this post but none worked so what i did was, on the GiTHub client i went to tools -> settings and then click on the section where it says add/create default ignored files. Then hit Update and try to commit again through the client.
It happend to me when my project was opened in an IDE (Netbeans in my case), make sure non of the files you're about to commit isn't open in some program.
I checked the log file at C:\Users{user}\AppData\Local\GitHub\TheLog.txt and found this error:
LibGit2Sharp.LibGit2SharpException:
Could not open 'SomePath\SomeProject.opensdf':
The process cannot access the file because it is being used by another process.
I closed Visual Studio and the commit was then created successfully.
n.b. I removed actual file path in the above error.
If you are new user make sure that you have confirmed your e-mail. Had same problem and confirmation fixed it!
You can manually navigate to index.lock which is found inside the hidden .git folder of your repository location. Once you delete index.lock you will be able to commit as per usual.
The easiest way to navigate to the folder will be to click on the folder breadcrumbs inside windows explorer and add \.git and press enter.
Just delete 'index.lock' in the '/.git/' directory. Solved the problem for me instantly.
I had this happen to me and this is the easiest way to fix it:
Make a copy of your local folder that has the repo and remove the .git folder form it.
Delete the original repo folder with files.
Re-clone the repo from GitHub with the Windows client.
Delete all of the files that get cloned except for the .git folder.
Copy all files from the copied folder into the new clone folder.
Add in your commit notes and the commit should work this time.
I had the same problem and I fixed it by renaming one of the file because its name was too long. This fixed the problem.
Here is error message from git shell:
fatal: unable to stat 'plugins/com.napolitano.cordova.plugin.intent/example/app/platforms/android/CordovaLib/build/intermediates/classes/debug/org/apache/cordova/NativeToJsMessageQueue$OnlineEventsBridgeMode$OnlineEventsBridgeModeDelegate.class': Filename too long
I REBOOTED my Windows 7 machine and tried again - IT WORKED!
I had the "Commit failed: Failed to create a new commit" and tried to delete the index or index.lock file via windows command prompt and that didn't work. I deleted it via windows explorer, that didn't work.
I tried to check credentials like another reply in this list said, but couldn't figure it out and the credentials seemed 'ok.' So - I rebooted. Viola.
I'm not sure this will help anyone, I'm not all that great w/ this stuff, but trying.
I deleted ".git" in children directory and the problem was resolved.
It happened to me once ,I had a empty repository inside of the repository that I cloned.
It was a silly mistake though but could happen .
[answer auto-selected by bounty system against my will]
I'm using subclipse, and always when delete a folder in Eclipse, and try to commit it, the following errors raise:
svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)
Deleting and commiting via command line works fine, but what's wrong with doing it via subclipse? Is anyone more experiencing this problem?
(I experienced this problem in Ubuntu 9.10 and 10.04; last Eclipse version; and subclipse 1.4 - as the next versions of subclipse have much more bugs)
--updated: Its when I delete folders, not files
Isn't that addressed by the Subclipse FAQ?
Whenever you see "out of date" in an error message it means that the revision of the item in the repository is newer than the copy in your local working copy.
The solution is always going to be to run an update, so that your working copy is up to date with the repository, and then do the commit again (assuming that the update did not generate any conflicts).
For files, this is usually pretty easy to understand how and why this happens.
However, Subversion also versions folders, and it is usually with folders that this problem most often happens.
Subversion does not allow you to delete/rename a folder OR change its versioned properties, UNLESS the local copy of the folder is at the HEAD revision of the folder in the repository.
Your next question might be:
"OK, I can maybe understand that, but why is my folder out of date? I am the only person working in this repository."
That is a valid question, the answer lies in the way that Subversion works.
When you commit a change to a file, the revision of the file in your working copy is updated to that new revision when the commit completes, however the version of the parent folder(s) of that file is not updated.
This is because there may have been adds/deletes to other files in that folder and until you have run an update, the folder is not really at that new revision.
This is called "mixed revision working copies".
In summary, the answer is always to do an update so that the folder or file is updated to its HEAD revision.
About "Mixed Revision Working Copies":
One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers.
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa.
Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people.
The fact is, every time you run svn commit your working copy ends up with some mixture of revisions.
The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions
(and that is why, I believe, you cannot reproduce your "out of date" message on subsequent commits with folder deleted: your update did solve the "mixed revision" state.)
Mixed revisions have limitations
You cannot commit the deletion of a file or directory that isn't fully up to date.
If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.
i think if you UPDATE before that it should work.. it did work for me
There's a simple solution without installing some extra software. I also had this "problem" and what you can do is the following:
1) open the SVN Repository view
2) there go to the folder you want to get rid of and delete it
3) go back to the java view
4) update the folder in your project you actually deleted / update your project should also work
That solved the problem in my case, as updating only retrieved the files I deleted
Subclipse has many problems like this. It works 90% of time, and then it just DOES NOT work as it should! I am using subclipse, since it is very well integrated into eclipse, and when I have problem or some bigger moves needed in svn (like merging some branch) I use Tortoisse.
I had the thing with directory like you. Then I just run the TortoiseSVN like #luiscolorado suggests, and it helped. Tortoise is so great tool (it has many great features for diffing, applying patches, getting patches and so on.).
Today I had a problem when I have removed a file, and someone had changed the same file! Then subclipse shows conflict (up to this point everything is ok), so I wanted to revert! But then the revert button is missing (disappears when inconflict mode!) so I have to do merge, and merge does not work, throws some kind of error. I didn't bother to read (maybe I should read and file it as a bug to subclipse maintainers ;-(), I knew the tortoisse will work, and you know what, it worked. There was a REVERT option.
So #Tom Brito, try command line, try Tortoisse, and then you can look at the subclipse changelog and file a bug. I think that subclipse just forgets to show us some directory changes and updates (or it is designed not to do it?), but I may be wrong.
Tom,
You might want to try TortoiseSVN, and manually update the project workspace. Find the location of your project directory in your hard drive, and then try TortoiseSVN (or the command line if it's your preference) to do the update.
A frequent cause of this problem is to delete the directory without "informing" SVN. For instance, if you manually delete the directory using the operating system instead of using SVN, you will have this problem.
If you removed the directory before you installed the subversion plug-in, but the project already existed in the repository, you will experiment this problem. A solution, in this case, would be to recreate the directory, updating/committing, and then delete again the directory.
Good luck.
My solution to this was
Delete all items in folder
Commit to repository
Update folder to HEAD
Delete folder in Eclipse
Commit to repository
A bit cumbersome, maybe, but it always works
The only working way in same cases is via command line. The subclipse is still not perfect..