Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve discussion of checking in Pods directory #67

Merged
merged 3 commits into from
Apr 22, 2015
Merged

Improve discussion of checking in Pods directory #67

merged 3 commits into from
Apr 22, 2015

Conversation

smileyborg
Copy link
Contributor

As per @orta's suggestion, here are some suggested improvements to make these 2 sections much clearer. I and the other folks on my team had trouble understanding this as it was originally written without reading it a few times, hopefully this is clearer!


Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend against adding the Pods directory to your `.gitignore`. However you should judge for yourself, here are the pros and cons:
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 do not add it to your `.gitignore`. But ultimately this decision is up to you:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not -> don't

@orta
Copy link
Member

orta commented Apr 21, 2015

Yeah, I'm good for merging once Restkit 0.10.3 is fixed 👍

Thanks @smileyborg - this is really useful.

- Smaller repo under source control
- CocoaPods given the availability of the sources is capable to recreate (almost) the same exact installation.
- No conflicts to handle in the dependencies of the management system of source control.
- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading this a few times I'm not sure if it makes sense to say no Internet connection is necessary since you would need internet connection in most cases to clone the repository.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I like having it in there. You're right that cloning will most always require Internet. However, sometimes you will clone a repo but not actually open/build its contents immediately...for example you may clone or pull the latest before hopping on an airplane. If you forget to also pod install and the Pods aren't checked in, you wouldn't be able to build on your flight.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd agree with @smileyborg here, there have been a few occasions where I've cloned a project before getting on a train but forgotten to pod install.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sometimes I work on a quick test project that I don't really want to push on GitHub, so I do my commits only locally, copy my working copy on an USB drive to bring it home to do some more commits, etc… so in such case, no remote and no internet connection required at all. So even if it's not the most common case, it still does make sense to me anyway ;)

@orta
Copy link
Member

orta commented Apr 21, 2015

🚢

available. CocoaPods will honour this version unless the dependency is updated
on the Podfile or `pod update` is called. In this way CocoaPods avoids headaches
caused by unexpected changes to dependencies.
Running `pod install` will install the current version of RestKit, causing a `Podfile.lock` to be generated that indicates the exact version installed (e.g. `RestKit 0.10.3`). Thanks to the `Podfile.lock`, running `pod install` on this hypothetical project at a later point in time on a different machine will still install RestKit 0.10.3 even if a newer version is available. CocoaPods will honour the Pod version in `Podfile.lock` unless the dependency is updated in the Podfile or `pod update` is called (which will cause a new `Podfile.lock` to be generated). In this way CocoaPods avoids headaches caused by unexpected changes to dependencies.

This file should always be kept under version control.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should emphasis this last point / sentence way more than that IMHO.

I still have encountered people adding Podfile.lock to their .gitignore. They generally just don't understand the consequences and e.g. think that using fixed version in their Podfile is sufficient to ensure fixed versions for all pods (not thinking about transitive dependencies).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok nvm, that point is already repeated above in line 72 so having it twice is probably enough.

@orta
Copy link
Member

orta commented Apr 22, 2015

Alright, let's get this in.

orta added a commit that referenced this pull request Apr 22, 2015
Improve discussion of checking in Pods directory
@orta orta merged commit 12fd2a0 into CocoaPods:master Apr 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants