I'm working in a group using GitHub, and when I tried transferring my work to the remote repo it didn't allow me to. It says I must do git pull first, so I did. That created some conflict in my code, then I tried to do git push again and that didn't work either.
So I switched to a new branch and tried to push from there. Didn't work with a simple git push, but a similar instruction worked for me.
Since then cmder keeps showing this:
C:\laragon\bin\cmder\vendor/clink.lua:219: attempt to index local 'HEAD' (a nil value)
C:\laragon\www\pharmacie>
Which allows me only to use instructions like php artisan serve, but not Git instructions like git status...
I already tried some clink.lua code that I found on github, but didn't work.
I tried abandoning my project, so I cloned the remote repo locally.
But then it didn't clone the vendor folder or the .env file; so I added them from an other repo (so it could compile) and changed the DB name in the .env file to match my project.
Now it keeps giving an error that says the table of the project I got vendor + .env from doesn't exist. But I didn't leave that table in the .env, I changed it to my project.
Any help?
Your problem is probably due to a conflict in a file you didn't handle.
When there is a conflict, a file usually looks like this:
<<<<<<<<< HEAD
// Some code
==============
// Some other code
>>>>>>>>> branch
And you have to choose what you want to save and what you want to delete after the merge.
So I would recommend to you to check your C:\laragon\bin\cmder\vendor/clink.lua file at line 219 to see if it could contain what I just said above.
And by the way, you should add your vendor folder in your .gitignore
And for the problem with your .env file, did you run php artisan migrate ?
EDIT
And because the problem come from your vendor folder, you could resolve it by deleting your vendor folder and run composer install to reinstall your dependencies
I have been facing the same issue. I resolve the issue by updating the cmder.
As like the image above for that click on the upper right corner (Setting) on the cmder window.
1. Choose: General -> Update
2. Check the Startup checkbox for (Do automatic check on) and then
3. Click the save settings button
4. Restart the cmder.
5. It will prompt for update and allow it to update.
6. Restart cmder again and it will resolve the issue.
I repair it as follows:
clone the repository again into another folder
access the hidden .git folder and copy only the folders (hooks, info, logs ...), do not copy the files
replace the folders in the .bin folder of the newly cloned project with the old one
with this I recover the branches and the code of my project, I hope and it will be useful to someone.
I've just updated to Xcode 7 general release and ive tried committing files. Its failing however, and im getting the following message;
Ive seen this question but the secondary response is different in the OP question: Xcode and Git Source Control : “The working copy XXXXX failed to commit files”
Whats the 'helper application' that it is looking for and whats the solution? Migrating to Xcode 7 and iOS9 is becoming a headache :(
I commit my files by going to 'Source Control' -> 'Commit'
Turns out the “helper application” is in fact Git. For some reason Xcode 7 is eager to associate you (the committer) with a name and an email address.
To fix it, on the command line, type the following:
xcrun git config --global user.email you#yourdomain.com
xcrun git config --global user.name "Your Name Here"
If the above mentioned solutions don't work, try this one:
Add changes once with a git command. Use terminal and change to your working directory (that contains a /.git folder) and execute:
git commit -a -m "Commit title here"
After that commit via Xcode should work again.
I had the same problem.
This fixed my problem: Quit Xcode(using CMD+Q) & run it again.
The above solution did not work for me. I am running on Xcode 8 (8C1002) and I have close to 4500 files to commit at once (adding the sources of a library to my project).
The only way I can make it working (without the error message) is by committing smaller number of files multiple times instead of all at once.
This happens to me when I add new image assets.
The "fix" is to go to File > Save BEFORE you do a Git Commit.
Then the Commit works Fine.
first you check in command line follow this picture .If git is clean (add . + commit done)
also have problem same you ForceQuit Xcode and open again
I just got an error after a recent commit using Tortoise Git:
"Could not get all refs. libgit2 returned: corrupted loose reference
file"
which pops up when I go to check the Log.
Any ideas on how to rectify this?
Your refs are stored inside the raw repository (in .git) in directories (named for each branch) under the "refs" directory. The problem is that one of these files has been corrupted. If you check the code here you'll see that the problem is either that the ref file is less than 40 bytes long, or has a 41st byte that is not a space (or tab, newline, etc). Search through the files in the .git/refs directory and you'll find the bad one. It should contain the 40-character hash of the commit which that branch refers to. You can safely fix it using Notepad.
In my case it was the use of "junction tool" (sysinternals). Got that error only when adding new sub directory and files. Using git bash the problem does not occur. Everything else works fine with "junction tool" and TortoiseGit ...
I had the exact same error and managed to get my repo back without losing my changes.
I:
Made several backups of the corrupt git repository just in case
Cloned the lasted pushed version from the remote repository
Copied all the files from the corrupt .git folder EXCEPT all files related to HEAD, FETCH_HEAD, ORG_HEAD etc ... the most important are the refs, obj, and index
Ended up with a valid history, but corrupt index, applied the solution from this post How to resolve "Error: bad index – Fatal: index file corrupt" when using Git
And my repository was back working ...
To make sure I did not push anything wrong, I cloned again from the remote, checked-out the changes I wanted to save from the restored repository, and comited them fresh.
Using the GitHub Windows client I did a sync to pull remote changes to my local machine, but before finishing the sync, I ran out of disk space and the sync failed. Now I seem to have a bunch of local changes that are actually changes that were being pulled from origin. I tried to run git pull but got:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git pull
Updating b3a86e1..5afd74f
error: Your local changes to the following files would be overwritten by merge:
SourceLog.Interface/IChangedFile.cs
SourceLog.Interface/ILogEntry.cs
...
Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
Lib/MSBuildExtensionPack/4.0.6.0/Ionic.Zip.dll
Lib/MSBuildExtensionPack/4.0.6.0/MSBuild.ExtensionPack.dll
...
Aborting
So now I'm trying to discard the local changes but I'm getting:
C:\Users\Tom\SourceLog [master +4 ~26 -0 !]> git checkout -- .
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
fatal: unable to write new index file
How can I clean this up? (I didn't have any local changes before starting the sync.)
Update
Can't seem to reset head..
C:\Users\Tom\SourceLog [master +4 ~0 -0 !]> git reset head
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) y
Rename from '.git/index.lock' to '.git/index' failed. Should I try again? (y/n) n
error: Could not write new index file.
fatal: Could not reset index file to revision 'head'.
Looks like the following process had a lock on the .git\index file:
ssh-agent.exe
C:\Users\Tom\AppData\Local\GitHub\PortableGit_8810fd5c2c79c73adcc73fd0825f3b32fdb816e7\bin\ssh-agent.exe
I killed the process and ran git reset HEAD and looks like I'm back to normal now.
In my case, this was caused by using the same Git repo from both admin and non-admin command prompts. When last git pull was from admin cmd, the index was created by it, and then non-admin cmd had insufficient permissions to modify it.
My solution was re-creating the index (while keeping the worktree intact):
del .git\index
del .git\index.lock
git reset --mixed head
In my case I had to close the VS code which I opened with code . from a WSL Ubuntu terminal.
It can be a real issue, try to run your Terminal as Administrator instead of user. Worked for me
I was seeing this Rename from '.git/index.lock'... message when attempting to execute
git checkout -b my-branch
The fix for me was to run the command line as admin.
Specifically I was using the excellent cmder application as a non-admin, which resulted in the rename message appearing. By running cmder as an admin, then performing the checkout again, it worked fine.
Git 2.10 (Q3 2016, 4 years later) should improve the situation on Windows
See commit 05d1ed6 (23 Aug 2016) by Ben Wijen (Ben).
mingw: ensure temporary file handles are not inherited by child processes
When the index is locked and child processes inherit the handle to
said lock and the parent process wants to remove the lock before the
child process exits, on Windows there is a problem: it won't work
because files cannot be deleted if a process holds a handle on them.
The symptom:
Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
Should I try again? (y/n)
Spawning child processes with bInheritHandles==FALSE would not work
because no file handles would be inherited, not even the hStdXxx handles in STARTUPINFO (stdin/stdout/stderr).
Opening every file with O_NOINHERIT does not work, either, as e.g. git-upload-pack expects inherited file handles.
This leaves us with the only way out: creating temp files with the O_NOINHERIT flag. This flag is Windows-specific, however.
For our purposes, it is equivalent to O_CLOEXEC (which does not exist on
Windows), so let's just open temporary files with the O_CLOEXEC flag and
map that flag to O_NOINHERIT on Windows.
To discard local changes, go
git reset HEAD
Then checkout your old commit, delete the new one, and pull again.
git checkout "hashOld"
git branch -d "hashNew"
git pull
For me it was this error:
Rename from 'D:/dev/repo/.git/refs/remotes/origin/my-branch.lock' to 'D:/dev/repo/.git/refs/remotes/origin/my-branch' failed. Should I try again? (y/n)
Renamed "my-branch" file, retried, and "my-branch.lock" succeed in renaming, not sure if this is correct, but worked. Local changes in both master and my-branch were preserved.
I got this error several times in a row when running git reset HEAD in a project stored in a Google Drive folder, but after a few minutes the problem went away.
I removed index and index.lock (in the .git folder) and ran git checkout . to undo the changes and resolved, but if I wanted to commit the changes I would have run git add -A after git commit -m "description"
I ran into this issue and wanted to post the answer for future searchers. Windows confirmed only. I got this when my git repository was under a directory that requires elevated permissions, AND I was running git from a process(cmd.exe) that did NOT have permissions to write to that folder, thus it could not clear the lock.
The answer is simple, run as admin.
I've answered this on a similar question. Might help others too, quoting the same here:
"For if any windows user stumbles on this:
I faced same issue and it wasn't solved by permissions since I had all the permissions assigned. Removing index.lock didn't help either.
I tried with WSL and it showed this error:
Another git process seems to be running in this repository.
Based on this I quit every process run by VS Code (that is the IDE I am using) and voila everything back to normal.
Note: Merely closing VS Code didn't help, had to end all processes from task explorer.
On a larger point, try ending all the processes via which you were using git. For me it was just VS Code."
Original answer: https://stackoverflow.com/a/67615831/13404308
I had a similar issue with Git. The solution for me was to delete the solution locally through windows explorer, and then re-clone the repository. This removed all the files that were stored locally on my machine, and resulted in the
Rename from '.git/..' to '.git/..' failed. Should I try again? (y/n) y
going away. After I cloned the respository, I tried my command again(which in my case was GIT COMMIT) and the failure did not reoccur.
The issue came about when I was trying to resolve a merge conflict that was happening after merging a feature branch into the develop branch.
Either kill the process that is locking the file or if it is a new repo, del the .git folder rm -rf .git and start again with git init
I'm using Tortoise Git. I just opened a new Windows Explorer and it fixed this. (For command line Git maybe just open a new shell).
I had seem issue when I was rebase my branch with master. My solution is turn off all solution which are opening and reset hard my branch to origin and rebase again.
git init resolved my problem. I was getting below issue.
Rename from '.git/objects/pack/pack-XXXXX.pack' to '.git/objects/pack/old-XXXXX.pack' failed. Should I try again? (y/n)
This is caused when antivirus or OS defender (for example Windows Defender) is running.
The solution: turn off antivirus for several minutes make your add, commit and push.
Turn on antivirus.
It will work.
In my case, I had done a git pull as Admin, and my regular user no longer had sufficient permissions.
My solution was to reset ownership to my regular user.
Right-click on .git, and open Properties.
On the Security tab, click Advanced.
In Advanced Security Settings, next to Owner, click Change (even if it's already correct).
In Select User, select the regular user, and click Okay.
On the Security tab, under Owner, you now have a Replace owner of subcontainers and objects checkbox - Check this and click Okay.
I tried a lot of suggestions. At times, a commit would succeed, but then the error returned. At last, pausing Dropbox sync seems to have done the trick! I have no clue how Dropbox sync could cause this error for longer than a few moments (the time required to sync my 24K .git/index).
For my case, it was just Windows Explorer being open and it was opening the directory above the directory that I wanted to rename. After closing Windows Explorer, issue went away immediately.
I was using Bash Git as Administrator.
in my case, I was using vim on WSL and writing git command on Powershell so I quit vim and then I was able to switch branches
Restart your Source Code editor; killing a Process may work but is not polite_
I copied (in Windows 10) the whole project to a new folder. Pushed from there to the origin (at that no index problem issued). Then I returned back to the project directory, where the problem occured. Deleted .git directory. Initialized anew (git init). Added to the index (git add . ). Fetched from the remote origin and merged. That's all there is to it.
I change project permission
Then, I exit Code Editor
I tried to do a search for my issue and the closest thing that I could is this.
git Status Shows Same File Twice - But with different path slash styles
But it doesn't seem to be the same issue I have.
I was doing a commit and noticed that the same file was listed twice but with different case. For instance, Directory/resource.h and Directory/Resource.h. Now there is only one file in the directory resource.h. If I look at the file through Git Extensions they look exactly the same. There doesn't seem to be another hidden file, there is only one file.
So I tried to fix this by removing the resource.h file, committing, and then adding the file back and recommit again. Only one file showed up as added. I thought I fixed the issue, but now if I try to checkout a different branch I get the following error.
error: The following untracked working tree files would be overwritten by checkout:
Directory/Resource.h
Please move or remove them before you can switch branches.
Aborting
Done
I don't really have any idea what to do from here, I've only been using Git for a few months and I haven't had to do anything more complicated than merging branches and pushing and pulling.
This can happen in Windows if you have a repo with ignorecase = false and rename a file without using git. To fix, this should work
git mv -f Resource.h resource.h
git commit -m 'fix case'
and this should prevent it from happening again.
git config core.ignorecase true