I am trying to merge a development branch into master and I keep getting an error involving xcschememanagement.plist that reads: The data couldn’t be read because it isn’t in the correct format. I have already created a .gitignore file, as well as navigating to the file locations in terminal and running git rm --cached xcschememanagement.plist
Here are some screenshots of what I am seeing:
To solve the problem, you can locate xcschememanagement.plist, right click--->OpenAs---->SourceCode to find where the error happens and fix it. But you should always edit the info.plist with Open As > Property List to avoid messing up.
Related
"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.
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.
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
I use Mercurial as source control with the main repository managed on KILN.
At one point in time I changed my iOS project name from WeatherTimeMachine to weathertimemachine.
This resulted in a case change of several files and folders:
WeatherTimeMachine.xcode
WeatherTimeMachine_Prefix.pch
WeatherTimeMachine-Info.plist
In the meantime I've added a tag to a revision in KILN... So I now have:
a head in KILN
a head on my local repo with case changes
When trying to merge I get the following error message: "Mercurial case-folding collision"
How can I fix this?
If you're on Mac OS X, you don't need to export your repository to Linux or another foreign case-sensitive file system as suggested by the Mercurial documentation. Just use Disk Utility to create a case-sensitive, journaled disk image slightly bigger than your repository, copy your repo there, then remove the conflicting files and commit.
I have found some information here: FixingCaseCollisions, but somehow this did not work for me. Here is how I managed to solve this issue:
Make a copy of your existing repository folder (for safety). For example:
cp -r WeatherTimeMachine WeatherTimeMachineCopy
Fool mercurial into thinking the problematic revision is the current tip:
hg debugsetparents <bad revision>
hg debugrebuildstate
Remove the files which are causing the problem (-f is required to force the removal). Here is an example:
hg rm -A -f WeatherTimeMachine-Info.plist
Once all problematic files have been removed, commit the changes
hg ci -m "fixed collision-folding issue" -u michael
Then restore mercurial to the proper revision
hg debugsetparents tip
hg debugrebuildstate
After this the merge is possible and the problem is gone.
And now I can happily resume working with MacHg to manage my Mercurial repository and push my change sets to KILN.
This is a no-programming no-hg answer, but it solved my mercurial case-folding problems once and for all! For now anyway..
I gave up trying to avoid and "fix" the case-collision problems. That just looks ugly and you can never really "solve" the problem, only can do a workaround.
The only way (that I can think of) to really solve the problem is to have a case-sensitive filesystem. No need to reformat your entire disk, a single partition will do the job nicely.
I used the Disk Utility app that comes with the os, pretty straightforward, just remember to select Mac OS Extended (Case-sensitive, Journaled) when creating new partition. Also, note that the Disk Utility can resize partitions only by moving the end (not the beginning) of partition.
You can probably create a symlink to where your old source code lived, so no need to change the IDE settings and stuff (but I haven't tried this, just happy with the new partition).
We resolved this without resorting to a case-sensitive filesystem by issuing HG rename commands. Say you are having trouble because "Foo.txt" needs to be called "foo.txt":
> hg rename Foo.txt Foo.txt.renamed
> hg rename Foo.txt.renamed foo.txt
We encountered this problem when a file was deleted and then later re-created in the main repository with the same name, but different case. A branch repository that was created before these changes could not then be merged in, despite the changesets from the main repository having been pulled.
For Mac OS X, what worked for me is to simply copy the folder (duplicate works - cmd-D) and continue working on it, from the new path.
OSX same I wanted to clone a repo and I had case-folding error preventing me top clone.
If the repository has multiple commit simply clone an earlier revision with this command:
hg clone -r 7
Then add anything conflicting to the .hgignore file and update.
Error message :
"svn: Can't open file '/Users/username/Projects/myproject/trunk/project/.svn/text-base/filetoupdate.h.svn-base': No such file or directory"
Question:
I have an issue I've replaced a file in a project (in Xcode) with a new file (For reference and if this makes a difference, the new file has the same name as the one I deleted previously).
Now when I try to commit my changes in Xcode I get the error message detailed above and am unable to commit the changes (i.e. adding the new file).
In the file system view (in Xcode on the left hand side of the screen) the file has an R next to it (indicating Replaced in the repository).
Does anyone know how to fix it so I can commit the files?
Thanks
There is a bug or limitation in Subversion when using case-insensitive filesystems:
https://superuser.com/questions/303348/cant-checkout-in-subversion
This bug normally shows up when checking out a repository that contains two files whose names differ only in case. Of course, these cannot exist at the same time in the same directory on a case-insensitive filesystem. SVN could give a much more helpful error message, but it can't really solve the problem.
Your issue is a bit different because I assume the file filetoupdate.h (with the old case) no longer exists in your filesystem. So it's not a case conflict in the working directory. But I guess that SVN is trying to create the file in .svn/text-base with the new case, while the old one still exists, and that is failing (for the same reason).
You could try deleting the file from Subversion first, keeping the local copy (untested). The new copy must be removed from SVN control for the commit to succeed:
svn rm --keep-local --force FileToUpdate.h
And the old copy must be removed as well, to allow us to add the new copy later:
svn rm --keep-local filetoupdate.h
Commit this change:
svn commit
Now hopefully you can add the new file to version control:
svn add FileToUpdate.h
If that doesn't work, you might need to blow away the whole checkout and start again with a fresh one.
Are you on a Mac or Windows? Those have case-insensitive filesystems which causes the above problem when
a file currently exists with the same name but with different cases.
To fix , checkout out the tree on a Linux machine, then "svn rm" one of the files.
Maybe your local version has permission issues. Check if your user have the permissions to write for the .svn directories.
good luck
It looks like something got confused somewhere. To fix, I simply copied the offending files, saved them under a new name. Removed the originals from the project and the added the copied (renamed) version of the file to the project.
It seems to be that SVN doesn't like it if you add and remove a file with the same name. I tried cleaning the SVN through terminal, but it had no affect on this issue. But changing the name did work for me.