The working copy “Pods” failed to commit files - Realm Errors - xcode

I am unable to commit my Xcode project changes to Github due to the following error. As you can see below, it's related to Realm. I updated the pods recently. Any advice on how to fix this.

Assuming you want to commit your Pods directory to Git, which ensures that your projects can be always compiled when you checkout a certain revision without having to run pod install before, then you could reset what you have in your staging area in the Podsdirectory by running the following commands in your project directory:
git rm --cached -r Pods
git add -A Pods
(Disclaimer: You can lose data by running such commands. Please familiarize yourself with what they mean if necessary, so that you don't delete by accident what you want to commit.)
Alternatively, you can add the Pods directory to your .gitignore file. This will ensure that you can't commit the Pods directory in future, but it will be necessary that pod install is run after changes to the Podfile.lock when e.g. switching branches, collaborating and on CI.
You can achieve that by executing the following command on the shell in your project directory:
echo "/Pods" >> .gitignore
After doing that, you need to commit the changes to your .gitignore to your repository. Furthermore I'd recommend to make a dedicated commit to your repository where you remove the files under the Pods directory. This will then affect only the repositories contents and not your local checkout.
The CocoaPods Guide "Using CocoaPods" has a chapter "Should I check the Pods directory into source control?", which discusses in length the advantages and disadvantages of that:
Should I check the Pods directory into source control?
Whether or not you check in your Pods folder is up to you, as
workflows vary from project to project. We recommend that you keep the
Pods directory under source control, and don't add it to your
.gitignore. But ultimately this decision is up to you:
Benefits of checking in the Pods directory
After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no
need to run pod install, and no Internet connection is necessary.
The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.
Benefits of ignoring the Pods directory
The source control repo will be smaller and take up less space.
As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation.
(Technically there is no guarantee that running pod install will
fetch and recreate identical artifacts when not using a commit SHA in
the Podfile. This is especially true when using zip files in the
Podfile.)
There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod
versions.
Whether or not you check in the Pods directory, the Podfile and
Podfile.lock should always be kept under version control.
In addition, you might want to check, whether your .gitignore can be improved. I can recognize from the screenshots for example that you have a xcuserdata directory in your Xcode project, which Git doesn't ignore. Those are user-specific configuration files and don't necessarily belong into a repository. If you collaborate with others, ignoring those reduces the size of the repo and the noise in pull requests and makes change sets easier to review. But as above it is ultimately up to you, whether you want to check them in or not. GitHub hosts a crowd-sourced repository with file templates for a wide variety of languages. Their Objective-C file might be good starting point for you.

Related

Cocoapods: how to delete one pod manually?

How to delete one pod manually with Cocoapods in Xcode?
I knew pod deintegrate, I have seen How to remove CocoaPods from a project?
It is too hard for me. Need more details, or a tutorial.
The reason of doing it:
I take part in an old, massive project.There are thousands of warnings there . So I want to maintain a personal version of the project.
When starting to delete one pod ,failed after running pod install
the warnings:
term pod install
Analyzing dependencies
[!] The version of CocoaPods used to generate the lockfile (1.5.0) is higher than the version of the current executable (1.4.0). Incompatibility issues may arise.
Cloning spec repo `z-appplatform-zspecs` from `http://git.zsys.com/AppPlatform/zSpecs.git`
[!] Unable to add a source with url `http://git.zsys.com/AppPlatform/zSpecs.git` named `z-appplatform-zspecs`.
You can try adding it manually in `~/.cocoapods/repos` or via `pod repo add`.
[!] Smart quotes were detected and ignored in your Podfile. To avoid issues in the future, you should not use TextEdit for editing it. If you are not using TextEdit, you should turn off smart quotes in your editor of choice.
The remote repos are of my company's server, I need authorization (secret).
After a lot of communication with my leader, he said "The pods don't need to update. And he can't give me the authorization to remote repo, he will manually do it for me"
Not convenient, with trying a lot to improve a massive project.

Why doesn't source control check in my CocoaPods?

I have a few Cocoapods installed for my project. For one particular pod, KVNProgress, Xcode doesn't commit it to GitHub. Each time I check my project out I get 'can't find KVNProgress.h' blah blah...
So I run 'pod update' from terminal and immediately all is fixed.
After running 'pod update', I check my project navigator and there are no 'A' or 'M' or anything else for that matter indicated a new or modified file. Therefor nothing to commit.
Any ideas how to fix this so I don't have to update the pods each time I check out the project?
You should use the Terminal to figure out if it's an Xcode problem or a git problem.
Run git status --ignored in the project directory. If the Pods directory is shown in the Ignored files section you have to remove Pods from your .gitignore file.
If the files appear in the untracked files section Xcode messed up the git status.
You can use git add . to add all untracked files.
As a side note, I would recommend to use a dedicated git client like SourceTree, GitHub Mac, or Tower instead of Xcode. Xcodes git implementation is not the best (feature wise) and it's a bit buggy.

Capistrano 2 -> 3 git deployment differences?

In my previous capistrano version 2 deployment of an app, I always got access to git on the deployed side with .git present. This was handy when in a pinch we need to make a couple of tweaks server side and push them back to version control.
Now that we're moving to capistrano version 3 we've been missing the .git folder and obviously no longer can issue git status, etc. on this deployment.
Is there an option I'm missing that has changed the functionality of cap 3 that removes git vs from a project upon deployment?
It does indeed USE git for each deployment, but it's obviously doing something after the deploy to remove .git, etc.
You can find the .git directory in #{repo_path} variable.

Cocoapods Private Repo not pulling correct code for tag

I was so excited to get a private CocoaPods repo working. I got v1.0 of my little internal library working with my main app like a charm. Then I added something to the library, committed it, tagged it with v1.1, pushed it up and everything went straight to hell.
No matter what I do, even though my main app reports that my internal library is pointed at 1.1, I keep getting the same code back as 1.0. I'm stumped.
Things I have verified:
My private pods repo has the correct folder structure, and the .podspec files in each folder have the appropriate s.version
Did a file compare of the two podspec files on my internal pods repo and confirmed that the only change to the file was the version number.
Did a git checkout tags/1.1 on the repo with the internal library and confirmed the 1.1 tag contains the appropriate commit.
Confirmed via the BitBucket website the file changes and tag for 1.1 made it there.
I have also tried the following things to resolve it (that I can remember right now) and still got the same code added in the Pod.
Removing the offending pod from the Podfile, running pod update to delete it, re-adding it, then running pod update again.
Clearing ~/Library/Caches/CocoaPods and [ProjectRoot]/Pods and running pod install.
Removing my remote pod repo via pod repo remove [NAME] and then re-adding it under a different name.
Pointing the podspec at :head
Pointing the podspec at the specific commit I wanted.
Pointing the podspec at my local copy of the library.
All this craziness points to some sort of caching issue with git or Xcode, but running CocoaPods in verbose mode doesn't seem to show anything other than super-temporary cache paths that get deleted the second pod update is done.
Anybody got any further suggestions? This is driving me bananas.
Update 1/24: I checked out the code under a seperate username and got some odd behavior:
pod install
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.0)
Installing Google-Mobile-Ads-SDK (6.7.0)
Installing LARSAdController (3.0.3)
Installing UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
[!] From now on use `[App Name].xcworkspace`.
Interesting, I thought, that it grabbed the 1.0 version even though I don't specify any version in the Podfile. So then I ran:
pod update
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.1)
Using Google-Mobile-Ads-SDK (6.7.0)
Using LARSAdController (3.0.3)
Using UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
And the code doesn't change, even though the version number increments. So this points to something I screwed up rather than a caching issue - but if I did, why the hell is it grabbing version 1.0 at all? Any thoughts?
Welp, this was a PEBKAC/not seeing the forest for the trees problem, which I realized when I tried to give up and switch to a git submodule and saw what appeared to be the same issue.
I'd pointed the CocoaPod at /[Project Root]/Library (and was initially looking in there when I tried to move to a git submodule), but when I'd dragged that folder into Xcode in the library project, I'd accidentally left the "Copy Items Into Destination Group's Folder (if needed)" checkbox checked. That created /[Project Root]/[Subfolder]/Library, where all of my changes were actually going. Once I fixed that, surprise surprise, everything worked fine.
So, uh, I guess the lesson here is that if you've gotten this far down the rabbit hole, step back and make sure there's even a rabbit you need to be chasing to begin with.

Added a large file to a git branch, committed changes, now the file is in every branch (including master)

I'm at a point where I realized I took some actions that were the equivalent of entering a cave without a flashlight. Hopefully this retelling of events will contain an indication of what went wrong.
I began at my project's master branch. I performed a git pull from the remote master (to make sure I had the most recent build), then a git checkout -b newFeature. With this newFeature branch, I made some changes, including adding a 700mb .mp4 file. I then committed my changes with git commit -a -m "New features and a big mp4 file..." I never pushed the changes to the remote. Made some more changes, decided I didn't want them, so I did a git stash at the end of the day.
This morning, I switched to master branch, where I did a git/status. I noticed my local master branch was now ahead of the remote master, which was odd because they should have been exactly the same. I also noticed that when I built my iOS app (from master, NOT newFeature) that the app size was 700mb bigger than it should have been.
Now this part is where I started panicking, so I apologize if the order of events is not completely accurate...
I saw that my .mp4 file was an unstaged file after running git status.
I tried to do a git reset HEAD <file>, which seemed to remove the file, but it still showed up in my builds.
I then tried git rebase, but never got through it because I seemed to hit a loop where all git rebase --continue did was end up at the same place over and over, so I aborted (I've never done a rebase before).
Giving up, I deleted all of my local files (or at least I think I did), restarted my computer (you never know), cloned everything from GitHub... and my builds are still including the large mp4 file.
I cannot seem to find the mp4 file, though it is clearly there when I build the app. I never pushed it to the remote, not that it would have let me anyway due to GitHub's restraints.
Any solutions, bread crumbs, or whatever would be greatly appreciated!! Thanks!
EDIT:
I attempted to go back to the build before I ever made the newFeature branch using git reset --hard , still no luck, as my project will still build with the mp4 file.
Perhaps I could find where this mp4 file is store locally? I can not find it in my project folder.
SOLVED:
See my answer below... long story short, I needed to Clean my build in Xcode (Cmd-shift-K) to remove the MP4 from the build folder.
Try git clean to remove any extra files. You should also check the logs of your build system to find out where this file is getting included.
Of course it's something I should have done right from the get-go. I've read before, "Before building your project, do a Clean on your build" (Cmd-Shift-K in Xcode). After running a disk report on my drive (using JDiskReport), I found the mp4 file cached in Xcode's DerivedData folder in my Library folder. Doing a Clean on the build removed the file from this folder, and no other future builds included it.
I guess I never ran across a time when not performing a Clean was really evident. When I was restarting Xcode, I wrongly assumed any sort of cache clearing would be done then.
So turns out this wasn't a problem with git directly, but with Xcode. I'm not sure if it should be the correct behavior or not, but I will now be run a Clean whenever switching between branches.

Resources