Non-existent file in limbo prevents push to remote branch (Bazaar VCS) - push

I use Bazaar VCS to version files locally on my notebook. When im in the office I merge the changes to a repository on a windows share and also push all the files there (for backup reasons).
My Problem:
The last push resulted in an error, because I added a file with a very long filename (I had that problem before ... python doesn't like long filenames). So I removed the file (I didn't need it anyway) and forgot about the problem for a while, because commiting still worked fine.
The next time I wanted to push my new revision I got a new error:
bzr: ERROR: [Error 3] Das System kann den angegebenen Pfad nicht finden: u'//path/to/remote/branch/.bzr/checkout/limbo/new-8/loooooooongfilename.xls'
translation:
bzr: ERROR: [Error 3] The system can't find the following path:
What I've tried:
Deleting the limbo folder--> limbo folder doesn't exist
Create the missing path with a dummy-file --> bazaar locks the branch --> unlock --> same problem as before
bzr check --> Everything is fine --> No success
bzr reconcile --> No success
Thanks for reading ;o)

Use bzr revert (possibly with -r 1234 to a specific version). Try it first on the specific file:
bzr revert -r 1234 path/to/myFile.php

Related

How to end 'another git process' running in same repository?

After my first attempt at committing a couple of large folders (angular and django), git responded with:
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
Previous posts recommend:
removing the index.lock in the .git folder.
I've done this, but the second that i resubmit "git add . " as part of my git push origin master routine, the index.lock file reappears in .git
Is there another solution? And what has happened to warrant this?
I've tried all the suggestions in the commented link
I'm working with this:
git version 2.13.5 (Apple Git-94)
In my case, index.lock wouldn't delete. Instead, I found that one of my django folders lacked a .gitignore, so I created one and included the following files:
include
lib
include
bin
.vscode
You might want to include more or less, depending.. Apparently, I was attempting to push a file that disagreed with git.

EGit push to remote is opposite what I expect it to do

This is what I want to do:
use Eclipse and Git (EGit)
use EGit to clone a remote repository to my local copy
make changes to my local copy
push those changes back to the remote repository
This is what I see:
after the push, the staged changes on the remote repository are the opposite to the changes I made.
Let me give an example and maybe someone can tell me where I have gone wrong.
I create a directory called C:\GIT\remote which contains a file called readme.txt which contains the string Hello World!
I turn this into a Git repository, I stage the readme.txt file, it shows:
new file mode 100644
## -0,0 +1 ##
+Hello World!
I commit this change at the remote repository. The remote repository contains no unstaged changes
Start Eclipse, import->Projects from Git->Clone URI. Location URI = C:\GIT\remote, Next, Next, Destination Directory: C:\GIT\local, Next, Import as General Project, Next, Finish
This creates a git repository in C:\GIT\local, with the readme.txt file and a .project file. As expected.
In Eclipse, I open the readme.txt file and edit it to say Goodbye World!. Save.
Right click on project in Project Explorer and: Team->Commit
Files to change are: readme.txt and .project. I enter a commit message "made changes" and click Commit.
Eclipse now shows that the local repository is 1 commit ahead of the remote repository. (Am I right?)
Right click on project in Project Explorer and: Team->Push to Upstream and it shows my comment and the remote repository details:
Now, when I look at the Staged files on my remote repository, I see this:
It's showing that the .project file needs to be removed (instead of being added), and that the change to the readme.txt file should be the reverse of the change I just made:
## -1 +1 ##
-Goodbye World!
+Hello World!
The C:\GIT\remote\readme.txt file contains the string "Hello World!". The staged patch doesn't even make sense according to the contents of the file.
I am puzzled.
No, those are the staged changes on remote. Not the commit history (the git log). Those are two different things.
The "Git GUI" is showing you the changes that you would need to commit directly to the remote repository to bring it into sync with the remote repository's working directory, which is still in the old state - out of date.
To avoid this confusion, developers often make the remote repository a bare repository - one with no working directory. Then it can only be pushed to and pulled from - not committed to directly.

Github windows: Commit failed: Failed to create a new commit

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 .

github - Adding a file to branch

So I'm following these instructions: http://mark-kirby.co.uk/2008/using-git-and-github-on-os-x, and so far I've cloned the project I want to work on and created a branch.
Now I wish to add files that exist in another folder on my machine, but I keep getting the following:
fatal: pathspec 'Users/mic/OnePageCRMVC/MKTsite25-05/index.html' did not match any files
However, the file definitely does exist...
Am I trying to do something that is not allowed and the error message is throwing me off?
You cannot add them automagically. You should copy the files into the git repo manually, then do a normal add/commit.

cvs error on checkin

When trying to commit to a cvs branch after adding a new file I get this error
Assertion failed: key != NULL, file hash.c, line 317
Any idea how to fix it so I can check my code in?
Both server and client are Linux and there are pre-commits involved.
sleep-er writes:
Not sure what the issue was but I solved it by going onto the server and deleting the file Attic/newfile.v in the repository and adding it again.
The "Attic" is the place where deleted files go in CVS. At some point in the past, someone checked in newfile.v, and at some later point it was deleted, hence moved to the Attic.
By deleting the ,v file from the repository you corrupted older commits that included the file "newfile". Do not do this.
The correct way is to restore the deleted file, then replace its content by the new file.
According to http://www.cs.indiana.edu/~machrist/notes/cvs.html
To recover a file that has been removed from the repository, you essentially need to update that file to its last revision number (before it was actually deleted). For example:
cvs update -r 1.7 deleted_file
This will recover deleted_file in your working repository. To find deleted files and their last revision number, issue cvs log at the command prompt.
Edited in reply to comment to explain what the ,v file in the Attic means.
Are you on Windows and did you rename a file to the same name with different case (e.g. MAKEFILE vs Makefile vs makefile)? CVS used to have a problem with this (and maybe still does?):
OSDir/mailarchive - Subject: Re: hash.c.312: findnode:
Manu writes:
I try to rename "makefile" to "Makefile" in my cvs tree, then:
cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
cvs [server aborted]: received abort signal
CVS was never designed to cope with case insensitive file systems. It
has been patched to the point where it mostly works, but there are still
some places where it doesn't. This is one of them.
You might want to read the rest of the messages in the thread as well.
Perhaps there is some kind of pre-commit check on your repository, see here
Not sure what the issue was but I solved it by going onto the server and deleting the file Attic/newfile.v in the repository and adding it again.