Github Pull Request for Just One Commit

I have a forked Yii which I use as a submodule in a couple of my applications. I haven’t made many changes, but most would probably not be useful most people. i.e. I put a conditional in that checks the version of PHPUnit and if it’s older than 3.5 it uses a different include file. Thereby letting me get around the limitation I have in one of my development environments.

My last commit, however, directly relates to an issue Yii had identified. So I wanted to push only that last commit upstream.

First make sure you have the upstream remote.
Then fetch from upstream — this creates upstream/master.
Then we create a new branch calling it upstream — not to be confused with the local remote we just created with the same name.

cd yii
git remote add upstream git://
git fetch upstream
git checkout -b upstream upstream/master
git cherry-pick
git push origin upstream

Then use something that was new to me, cherry-pick and give it the hash of the specific commit. That will merge over only that commit to the new branch you made. Then just push it.

From github, you can then make a Pull Request from that specific branch and contribute. Since that’s what it’s all about.

Helpful links:……

Git Template Application Repository

I titled this post what I wanted, but the result wasn’t quite so succinct.

What I wanted was a git repository that contained a template for future applications. I have done so much what I’m considering good work with Quizmo, I wanted to create a skeleton framework that I could fork into applications. So all of the components that I’ve created could be contained in one place and when I update them in Quizmo, they would likewise be updated in the template repository, and future applications would be able to easily pull down those same changes from the template repo. So I could really live the dream of rapid development RoR has been trying to sell for the last decade.

My first thought was to create a repo that had a dummy application in it and just forking it. Then I should be able to pass things back via the upstream and down with merges. It seems like such a simple operation. Unfortunately, that’s not how forking works. The problem is if you want to merge upstream, you have to merge everything. You can’t just merge the things that are in the upstream, there’s no mechanism for adding or committing one revision without committing every revision prior to that one.

So the only way to have different components connected via other repositories is to have multiple submodules. Everything needs to be contained in its own directory. There’s also fake submodules*. Which just relies on a lot more setup, I haven’t encountered problems with using submodules yet, so that isn’t an issue.

Instead of having the awesome application template repo I wanted, I’ve got a bit of a mish mash which currently looks like this:

The most important thing with this discovery of using a mish mash of submodules is that I should modularize my code. That is to say I need to have all related components in the same place. That seems obvious, but when going with the flow of yii, I put things where yii wanted them, not necessarily where they would be best served. Like twitter bootstrap, which got just strewn about all over the app.

The authentication abstraction I’m using is an IdentityFactory that chooses which xIdentity component to use which is an extension of UserIdentity but each individual xIdentity calls on its respective extension. So do the xIdentities go with the appropriate extension or with the IdentityFactory/UserIdentity? Asking the question makes me think it has to be with the extension.

Interesting links:

* Update: Upon working more with submodules, and paying attention to the pitfalls (outlined here) I’ve actually become very opposed to fake submodules (see above). Fake submodules relies on the person checking out your code to check everything out, and leaves the repository with no explicit link to the submodules. You basically just have to know. Which is fine for one guy working on one project, but is horribly irresponsible for a developer working for anyone other than themselves.