Master does not run in Xcode build due to missing bad App reference

[phoboslab]

Master does not run in Xcode build due to missing bad App reference

[phoboslab]

Well, yes. Hence the updated readme. Explanation here: #34

Maybe there's a better way to do this?

[amadeus]

It needs to keep a reference, so when you add your App folder to put your application in it, it will continue to work.

Having to setup Xcode to support this app folder would be a PITA.

[mrspeaker]

Moving the App folder out of the project is good - but how do you manage renaming your project? If I rename the xcode project then the project.pbxproj file and plist stuff will be modified and will show up as modification in the repo.

I want to be able to pull any changes to Ejecta, but I don't want all my xcode projects to be called "Ejecta". Is this possible?

[theshortcut]

I think it'd be nice to set it up similar to the Sparrow Framework scaffold. Set an environment var for the Ejecta repo path and have Ejecta pulled in to your Xcode proj as a sub project/target. That way its easy to duplicate the scaffold project and rename things, but always have the Ejecta core up to date and even across multiple projects.

[amadeus]

@mrspeaker Here is how I manage both in parallel (it's also a quick lesson in how to take advantage of Git's distrubuted nature):

First off, a quick explanation of how Git works (you guys may already know this, but I will explain it all anyways so we are all on the same page):

In the default case, when you do git clone repo-url.com, you are actually making a copy of that remote repo called origin (git calls origin a remote) and then, by default, you are checking out a copy of origin's branch (called master) and creating a local branch, called master, that then tracks to that remote master branch.

The easy way to determine the differences between them is the name. If I call the branch master I am referring to your local branch. If I call it origin/master then I am referring to origin's master branch. Think of it like this: you own master but you don't necessarily own origin/master (in the case of Ejecta, Dom own's origin/master). In general, whenever you are making code changes, etc, you are simply interacting with the local branch. Unless you are getting deep into git, you really ONLY interact with local branches and never with origin's branches (other than git push and git pull).

A quick note: the name origin is just a default. You could actually change the name of origin to anything else, or even add other remotes by other names, but that's another topic for another time.

So in the case of Ejecta, when you clone that repo, you are actually making a copy of the Github's repo, and it's being labelled origin (owned by Dom). Then you are getting a local branch called master that tracks origin/master. Tracking is the term given to what your local branch pushes and pulls too.

You are probably used to using a command like git pull to update to get the changes that Dom has pushed to the repo. The command git pull is actually doing a couple things that I need to break down.

When you perform the command git pull it's actually doing 2 things. First it does a git fetch immediately followed by a git merge.

What git fetch does is update your origin. Basically you don't really interact directly with origin, you simply keep it up to date. When you do a git push you are essentially telling your local branch to update the origin remote base on your local branch changes (which you can only do if you write permissions to the repo, only Dom has write permissions to Ejecta), which in turn causes it to also try to push those changes to the server.

So back to git pull. When you do a git pull it will update your origin, then immediately merge those origin changes into your local branch, in the case of Ejecta, it would merge origin/master into master.

So to summarize: git pull = git fetch origin (origin is updated) + git merge origin/master (pulls the updated origin/master into master)

One thing you may or may not know, the local master branch is technically owned by you (even if the origin is not owned by you).

What this means is you can make code changes, and commit them to master. However, unless you are Dom, you cannot git push those master changes into origin/master (and by proxy updating Github's Ejecta repo). In other words, git clone git://github.com/phoboslab/Ejecta.git is mostly a one way street.

Now that I've explained the basics of how git works, we can discuss how to simultaneously manage your own and Ejecta's repos.

There are 2 ways to do this, 1 is to fork Ejecta to your own github account, the other is just a quick hack on what I discussed earlier. Forking is a bit more complicated, but the concepts from what I will describe essentially still apply. So here's the quick and dirty way of doing this:

First you need a copy of the repo: git clone git://github.com/phoboslab/Ejecta.git

Next, you should follow the README for setting up your app. Create the App folder, put your JS files in it, etc.

Next you need to launch the XCode project and perform all the XCode changes you need (updating the App icon, update the project name, etc).

Once this is done, simply commit these changes:

$: git add .
$: git commit

With the changes commited to master, you now have your stuff saved in your local branch. You can continue to add as many commit as you want/need. It really doesn't matter.

The next problem we need to solve is how to update Ejecta when Dom pushes out new changes.

The first thing to learn: we need to stop using git pull

Instead, you are gonna always start with

$: git fetch origin

Assuming there are changes, you will see some git output decribing that it pulled in some stuff, and what origin branches it updated. In the case of Ejecta, it's going to mostly just be updates to origin/master

At this stage you have a choice. You can update the clean way or the messy way. I recommend the clean way which uses git rebase. Rebasing is different from merging, it's a bit trickier but I find the results much cleaner. I am not going to get into the technical differences for now, just how to use it in this context.

So we've run our git fetch origin which updated origin/master with new commits. We now need to put those origin commits into our local master branch. We do that with the following command:

$: git rebase origin/master

This command essentially does the following: It rewinds the local master branch to it's last common shared commit with origin/master. Then it applies all of origin/master's new commits to master, then it replays your new commits that you made before, on top of that. There's the possibility of a merge conflict during this process, which you will need to solve, and then continue the rebase.

So to summarize, to stay up to date you do the following:

$: git fetch origin
$: git rebase origin/master

And there you have it, you can stay up to date with Ejecta, and also maintain your own changes, modifications, etc.

[mrspeaker]

Fantastic write up - thanks @amadeus!