Some overlap with 505 and 510.

I'm not sure what's going on here - you're reposting some changes from my fork in #510 in this pull request! If you backed out 3cc98ea and 3cc98ea, your changes would stand alone with no overlap.

While I'm here, how about some test cases for your phone number changes?

I thought I had your stuff in a separate branch. I'll also take a look at the tests.

No problem - I just noticed that GitHub doesn't let you fork a repo if you already have a fork of its parent.

I'm not sure why you're saying it's tested - I don't see any new tests for your changes, i.e. to prevent regression to the previous cases that passed when they should not have. I don't see why you backed out the changes in 032e9e8.
Also this is still treading all over my pull request which you copied.

Merged. Updated. Tested (TRAVIS: passed; LINT: passed). Ready to Commit.

I can't see your fork in Travis-ci, and the 'details' link above doesn't point at anything useful. Have I missed something?

Have I missed something?

Yes, look at the red and green dots over to the right side of the box, but only on recent commits.

If you merge your repo with the master, you'll get your first personalised Travis report this way too.

Merged. Updated. Tested (TRAVIS: passed; LINT: passed). Ready to Commit.

Does this still overlap with #510? Would be good to merge that separately. Also an interactive rebase to squash most of the fixup commits would help. Btw. what are all the whitespace changes in test files about?

It does overlap with 510 as they are proposing something slightly different (and I guess 510 will throw errors in Travis).

The whitespace didn't seem consistent, tried to make it more so. Code alignment also helps readability.

Travis just runs grunt, so let's refer to that. Can you do the rebase and squashing?

Last time I tried rebase, it completely messed up. I'm a bit wary of it now.

Try git rebase master -i and follow the instructions in the editor. When done, check the log to see if it all looks good, before you force-push back to GitHub.

I'm not using Linux.

Its the same command on every system, its just git. If you're using a GUI tool on Windows, install msysgit.

I don't think it will help matters:

One of the vast uses of git rebase -i is reordering commits.Do NOT rebase commits that have been pushed publicly. If you’re working with other developers, that will make the merge non fast-forwardable and creates headaches for all involved. Yes, the command allows one to rewrite history, but only do so when the commits are still on your local machine.

Really, your repo is really a private one that happens to be publicly visible - nobody has made any forks from it, so don't worry about it, go ahead and do the rebase.

Yep, I wouldn't have asked for a rebase otherwise. That warning very much applies to commits pushed to this repo's master branch. But not to other branches or even forks.

-> "Nothing needs rebase; master equal remote/origin/master".

You're missing the point - rebasing will convert the 16 commits in this pull request into 1, making for a much tidier merge upstream. The result is the same, it's just less messy.

I think @jzaefferer was talking about this kind of rebase http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html not just playing back your commits onto of the remote master.

Rebased onto master, squashing into a single commit and fixing a few lint issues.