We're using svn for version control on our Mac. Its working cool. But the only problem is we're multiple devs developing together and everyone can see any file changes status inside their Xcode ( attributes next to the file ) in their Xcode except me. How to resolve this?
This is what I want (see "M" next to the file name),
Even Xcode Source Control Menu is showing no changes.
I'm not sure if there's anything to set here?
I have checkout the code again and again, but still the problem persist.
I'm not sure, why this "Working Copies" menu "iOS" is disabled? Its enabled on other machine.
Any help would be highly appreciated.
I also encountered this problem, the following is my solution, hope I can help you.
Start the terminal, enter the code in the folder.
Type the command - svn status.
The output will be similar to this
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Users/chao/svn/project'
is too old (format 29) to work with client version '1.9.4 (r1740329)' (expects
format 31). You need to upgrade the working copy first.
Type the command - svn upgrade.
The problem is resolved,I wish you good luck.
SVN can define status of working copy files and directories comparing your local files with the current repository located on the remote SVN server.
I believe that checking "Refresh server status automatically" will do the job.
You can say this is true when your local files will have attributes aside (U, M etc)
Having no luck, you may run the command line tool, which is usually more verbose. More details here: https://stackoverflow.com/a/19922150/195812
"Out of the blue" I've started having this issue with a git repository that I have hosted on GitHub.
Whenever I pull a remote branch to my computer (even on the first clone of the repository) an arbitrary (?) set of files appear as "Changes not staged for commit". I am running on Windows 8.1 and using SourceTree alongside Git Bash as git clients.
An examination of the changes in these files shows that nothing has changed in them, except, maybe, the line endings. I don't know how to view the line endings when diffing so can't be sure.
When I try to "discard" these changes, it simply doesn't work. git reset --hard simply has no effect and the changes remain in place.
Why is this happening? How can I make it go away? :)
PS - When I run git config -l I see core.autocrlf=true appear 3 times in the list.
PPS - I have a .gitattributes file in the root of the repository. Deleting it does not have any effect on the above symptoms. It was first added a few days ago. It's all commented out except for * text=auto in the beginning of the file.
UPDATE:
I've found the minimum steps to reproduce my issue:
I open a file in a text-editor, add a single space somewhere and save it.
The file appears under "Changes not staged for commit" (obviously).
I remove the single space from the file and save it.
The file remains under "Changes not staged for commit" even though both SourceTree's diff and Kdiff3 show that the file is binary equal to its previous version.
Please note that the file in this example had CRLF line endings before I edited it and after I edited it - I don't understand why git insists on marking the file as changed.
UPDATE 2:
Running git diff --raw MyProject/app.config where MyProject.app/config is one of the files marked as changed gives:
:100644 100644 b960510... 0000000... M MyProject/app.config
The fact that the second SHA1 is all zeroes looks like a clue to me - but I don't know what it means.
This is a common problem when you set core.autocrlf after the fact. You can try this procedure from GitHub help. Another easy solution is to just clone a new local copy of the repository, which can also be a good troubleshooting step if you're still having problems.
UPDATE 3: I was able to resolve my issue by removing the .gitattributes file from the root of my repository.
The most likely suspect for having added this file into the repo in the first place is Visual Studio 2013 are per this Microsoft Connect issue.
I still don't understand why having this file (with this core.autocrlf=true in it) caused the behavior that I observed. If anyone has a good explanation, please post it as an answer and I will accept it.
Following the github article on dealing with line endings you can see that setting text=auto on the .gitattributes file tells git to "handle the files in whatever way it thinks is best." Seeing that the rest of the file was commented, and you had a star on text=auto, this was applied on everything. I suppose that in your case, what git thought was best, turned out to be the wrong choice.
When I try to commit I get the following error:
The working copy "Chord Attack" failed to commit files. fatal:
Will not add file alias 'Chord Attack/GameResources/GUI/Chord Attack/chordattackbg.png'
('Chord Attack/GameResources/GUI/Chord Attack/ChordAttackBG.png' already exists in index)
I can't even find that file in my directory or anywhere on my computer. I deleted that from my project a long time ago. I even recreated my project and manually added files one by one and some how this happened again. I saw another post that said to delete the file and manually re-add it, but it didn't work. Currently, the chordattackbg.png file is in my project. I tried deleting that and then committing, but the same error came up. What am I doing wrong?
This is a case issue (chordattackbg.png vs. ChordAttackBG.png), as described in this question.
You would need to:
git mv ChordAttackBG.png foo
git mv foo chordattackbg.png
git commit -m "Rename ChordAttackBG.png to chordattackbg.png"
Then you would apply your modifications to chordattackbg.png, add and commit.
Here the solution was to:
clone the local repo again,
cleanup its content,
rename the file (ChordAttackBG.png to chordattackbg.png),
add the new modifications to chordattackbg.png,
re-open the project in XCode from the new clone.
I solved this problem deleting this file:
/path/to/project/folder/.git/index.lock
Then I could commit from Xcode with no problems. Hope this helps!
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
Post-installation of 10.8 and Xcode 4.4 when I try to push to a remote using the Xcode integration Xcode is telling me 'no remotes found'. I am still able to push successfully via command line so my actual repositories are fine. I've installed the command line tools and have tried restarting Xcode several times. Additionally, if I go to Organizer and try to select the repository all I get is a spinning activity indicator. If I select 'remotes' for a given repository it's blank. Note that Xcode does recognize git is available though as it does show which files are modified and allows commits. Reported system git version in /usr/bin/ is:
git version 1.7.9.6 (Apple Git-31.1)
Is anyone else experiencing this, or do you have any suggestions for a remedy (or at least a place to look at a log to see what is going wrong)?
UPDATE 10/18/13
This issue has been resolved in Xcode 5.
When you add the remote repository in Xcode or in command line (doesn't matter from where you add it) make sure that you use the full path for your repository.
E.g.:
From commandline it's enough to specify
git remote add <name> gituser#gitserver:example.git
when your example.git is located in gituser's home directory. However Xcode can't deal with this annotation and says "No remotes found" when you try pushing your commits to this remote repository.
In order to satisfy Xcode you should type the whole path like:
git remote add <name> gituser#gitserver:/home/gituser/example.git
I have found this solution for Xcode with Git:
Organizer > remotes > origin
1) remove old remote
2) add new remote:
remote name: origin
location: same as before, but replace all ":/" or "//" by "/" only
I had the same problem with Xcode 4.6.3.
Here are the steps I performed to resolve the problem:
1. In Xcode I went to File -> Source Control -> Repositories (which opens the Organizer)
2. I then selected the Remotes object from the tree for the Repository I was having the problem with.
3. My remote was named origin, however when expanding it, I noticed it did not have a Branch associated with it.
4. I then selected the remote origin and pressed the Remove Remote option, which removed the remote origin from the view.
5. I then went to a terminal and re-added the remote with:-
`git remote add origin http://username#localhost:7990/scm/iac/main-repository.git`
6. I then needed to add the branch(es) to this remote, which did not worked correctly initially, so I then forced it using the -f command. The command I used was:-
`git push origin master -f`
Note: It may have been possible to skip steps 4 and 5 and just go straight to step 6. I had removed the remote, so did not have the chance to test this.
Note 2: You will need to restart Xcode (or possibly just the Organizer) to see that the remote and branch are now available.
you need first add a remote repository: git remote add yourname https://github.com/user/repo.git
and than push... and xcode find the remote repo and can push too.
I've had the same issue with SSH defined hosts.
My ~/.ssh/config looks like this:
Host myGitServer
HostName {real address goes here}
{Some more config for the host here}
My repository remote URL was in the form of ssh://myGitServer/git/project.git
The problem was that XCode did not read the SSH config to resolve "myGitServer" so the repository was always "offline" for it.
I ended up adding "myGitServer" to /etc/hosts.
I guess that among other things, the "no remotes found" issue is caused when XCode can't directly resolve the name of the GIT remote server.
I had a similar problem where remotes were failing to load, specifically for kiln as the remote host. Looking in the git config for the repository info, the URL had been changed to prepend my email address to it.
So I simply exited Xcode, and then from the command line did:
git remote set-url kiln https://...kiln repo name.git
And that seemed to fix it when I restarted Xcode - both pull & push worked again.
I have no idea why Xcode corrupted the URL. This was with Xcode 4.6.3
1- search and apply the guideline. which is mentioned about "show all hidden files in mac finder". and delete .git directory (this folder wont appear without solving article-1)
2-XCode>Prefences>Accounts>Delete github account and close xcode. than open and reconfigure same github account by adding all over.
3-click the section small icon namely "source control navigation" (which is near the project navigator). as you right click a popup will appear. and choose create blabla on github". actually this steps solved same issue.
Xcode 10.2.1
Double Check:
1) Git Acc under preferences.
2) cmd + 2, right click under remote to create a remote.