This is my first time forking a GitHub project, and I'm not too competent with CocoaPods either, so please bear with me.
Basically, I forked a project on GitHub using the following in my Podfile:
pod 'REActivityViewController', '~> 1.6.7', :git => 'https://github.com/<username>/REActivityViewController.git'
I then made some changes to the fork, and of course when I did a pod install to install another pod it reinstalled the original REActivityViewController and erased my changes.
I'm realizing I need to push my changes to my fork before another pod install, but how do I know it is the fork being installed, considering that this is a repo installed by CocoaPods? I looked in the REActivityViewController folder installed under the Pods folder and there aren't any git files.
Do I need to work on my fork outside of my project and then use CocoaPods to install the changes? That's too cumbersome of a workflow.
Or do I need to do something with submodules?
I will answer this question using an example. I have a fork of TTTAttributedLabel with some extra functionality I added here:
https://github.com/getaaron/TTTAttributedLabel
In order to use this in a Cocoapods project, I:
Push my changes to my fork
Configure my Podfile to get the changes & update
Once you've pushed your changes to your fork, get the SHA of your last commit. You can do this using git rev-parse origin/master | pbcopy or on the GitHub commits page for your project:
Then, you can specify the specific commit on your fork in your Podfile like this:
pod 'TTTAttributedLabel', :git => 'https://github.com/getaaron/TTTAttributedLabel.git', :commit => 'd358791c7f593d6ea7d6f8c2cac2cf8fae582bc1'
After that, pod update will update this particular commit from your fork. If you want, you can also make a podspec for your fork, but I find this approach simpler and I don't make changes frequently enough to justify a new workflow.
Do I need to work on my fork outside of my project and then use Cocoapods to install the changes? That's way to cumbersome of a workflow.
You can do it this way, but I usually:
Edit the code inside my project and make sure it works
Copy the changes over to my fork, by
exporting a patch, or
copying over the entire source code file
Commit & push to GitHub
Update the Podfile with the new SHA
Run pod update.
Or do I need to do something with submodules?
No, you don't need to.
Another option is to have your project reference the pod directly and not via github. This way you don't have to keep committing your fork or copying/pasting code just to test your changes. You can work with two different Xcode projects simultaneously and commit separately into their respective projects.
pod 'AFNetworking', :path => '~/Documents/AFNetworking'
CocoaPods Documentation:
http://guides.cocoapods.org/using/the-podfile.html#using-the-files-from-a-folder-local-to-the-machine
CocoaPods and GitHub fork
You have two variants to work with fork
[Podfile specific branch]
[Podspec specific branch]
The difference is in the first variant you must push changes into remote/origin branch, while the second variant allows you just commit changes in a local branch
Related
There is a github repository that is no longer actively maintained. I want to use the code and move it into my project's components but that is tedious and not sure if that is the best approach.
I just want to bump the version of draftjs used by the repository.
Here is the repo and it uses draft js version 0.10.0
https://github.com/brijeshb42/medium-draft
My local project uses draft js version 0.11.7
This causes errors and incompatibility issues.
What is the best approach when a repository uses an outdated version of a repository used by local project?
Before forking and publishing to npm your own version of that dependencies, you might consider using the package/patch-package
Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package
# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"
In your case, you would be patching the brijeshb42/medium-draft/package.json file.
So I'm using a library that's been abandoned but I've made quite a few changes within its files under Pods. If the pods are reinstalled, the library won't work. What's the best practice for this sort of thing?
I have forked the project over and updated it with my changes.
Instead of having the line:
pod "PodToIntall"
I have
pod "PodToInstall", git: => "the url to my fork", branch: => "master"
If I try to pod install I get the error
[!] Unable to find a specification for 'PodToInstall'
The project is dead so if I can't get the owner to merge my changes is there any way to pull it off my github?
Check that all steps are done from the following list:
Change the source files from your forked pod project.
Commit it & push to GitHub (if pod is hosted here).
Update the Podfile within your main project to use forked pod.
Run in terminal pod update PodToInstall.
Also CocoaPods and GitHub forks might be useful.
I'm working on an Xcode project (Swift) that utilizes cocoapods. After completing my tasks, everything worked. I then committed and pushed to my GitHub repository. Then I downloaded the project as a zip from the repository to make sure everything was good. Everything looks fine, but the pods are not there. As a result, in the downloaded version the pods are in red. Is there any way to fix this?
(sorry if this is really simple, I'm just new to GitHub and I haven't found a solution anywhere online)
The question here is basically: How do I make everything compile after cloning/downloading my project.
It seems that you did not commit your Pods into your source control, so the short answer is: Just run pod install
If you want more details about wether you should commit your Pods or only your Podfile, and about Cocoapods in general, this guide is a good starting point.
When you push everything to github, you will need to check the “select all files”. so that your push to github actually sends the pod directory and the Podfile.lock.
Sometimes you need to manually go into the proj3ct directory in terminal and type “git add .” (Hope that’s the command)
Check your github repo and see if they exist and contain files.
You probably don’t have a .gitignore, but if you do, the. Make sure that you are not ignoring pod files. Otherwise they will never be written to the repository.
If the pod files are in the repo you shouldn’t need to do a pod install. But if all else fails, that’s what you need to do.
I've got Composer installed and I've used it to download HTMLPurifier locally. Now I'd like to push that download to my OpenShift Git repo. So, in a Git Bash window, I run the following...
git add -A :/
git commit -a -m "Uploading HTML Purifier"
git push origin master
At this point Git reports that the push was successful but when I ls the directory through SSH, it shows that the HTMLPurifier directory is empty. Why is that? How do I get Git to push those files?
Additional Info: I noticed that the HTMLPurifier directory is indeed a Git repo itself and contains a .gitignore file in its root directory. I tried deleting it and re-running the above commands but to no avail...
You should try to avoid pushing downloaded dependencies into a repository. It is recommended to add the vendor directory into the .gitignore file at top level. But what you must do instead is commit and push both composer.json and composer.lock.
Here's why: The vendor directory is managed by Composer. Running Composer will probably do minor things during an update, but may also be doing heavy stuff if the Composer team decides to optimize things.
Also, if you require a branch of a package, and Composer knows the repository of that package, it will default to cloning a Git repo or do a SVN checkout instead of trying to grab a ZIP package of that branch (often there is no way to get such a package for branches, and even tagged versions in a plain Git repository do not have such download ability. Composer knows that Github offers such downloads, and detects Github by looking at the repo URL.)
So you can assume that Composer will put a lot of repository meta data into the vendor file, and if you blindly commit these, things will get ugly. First of all, you are committing way too many files, increasing your repository by an unnecessary amount, which will slow down things. Then, if cloning Git repositories, these will be treated as submodules, and that has another bunch of nastiness I am told. If you are just learning Git, it probably isn't a good idea to start with these. And if you are sufficiently known to the tools (Git and Composer), you probably won't need them either.
There really is only one reason why you'd try to commit a modified version of the vendor directory: If your release process is completely depending on all files being present in your one repository, without any way to run a composer install during the release to make these files appear on the target server.
In such cases, you'd install or update the packages with Composer, and then go through all created directories and delete any .git and .svn (and probably also .hg for Mercurial) folders you encounter. Only then you'd be able to commit the files into your own repository.
But note that this step might be a tedious step to do manually - you probably want to create an update script that does all that work for you. You also might run into issues when updating dependencies because Composer expects files to simply go away when deleted, and not be in the way when being written. I cannot tell you exactly what you'd be experiencing because it depends on how you'd do stuff, but I expect you stumbling upon random puzzling issues.
Bottom line: Avoid committing the dependencies into your own repository if possible.
Try using the -force option, you will also most likely need to delete the .git directory inside the HTMLPurifier directory too.
I'm trying to use the gdata gem in a Rails project. The main development branch of the gem doesn't support Ruby 1.9 (it requires 'jcode', which isn't needed and doesn't exist for Ruby 1.9.x). There are forks which do, of course; it's a simple fix. However, to use the gem in a Rails project, I need a version which Bundler can find when I deploy, which means forks of a project using hg won't work (unless Bundler has Mercurial support to match its Git support now?).
The "obvious" solution to me is to clone the main Mercurial repository, make the fixes I need, and push this new branch to Github where my deploys can clone it. However, this seems somehow undiplomatic, because a side effect would be the establishment of an unofficial public Github repo of the gem. Is this kind of thing OK?
It's absolutely fine, as long as the license allows it. Don't forget to link back to the original repos, and clearly state what you are doing in the readme.