CODEWITHSUNDEEP
xcodeswiftgithubcocoapodsrealm
ckraider
ckraider

Reputation: 345

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

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.

enter image description here

enter image description here

enter image description here

enter image description here

Upvotes: 2

Views: 2600

Answers (1)

marius
marius

Reputation: 7806

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.

Upvotes: 2

Related Questions