Fixes/266 new google key

[reekypete]

Fixes #266

D of E has purchased an Enterprise license for Google Maps. This provides 1,000,000 Maps API Credits, and in addition offers graceful degradation when limits are exceeded (i.e. we will be contacted by Google and warned).

We cannot be sure how many people will use the school finder, particularly when it is first released. This license offers greater capacity and certainty than the existing (free) license.

[techieshark]

Commit 9034529 "266 - New google key" looks good, but a few comments:

1. In the body of the commit, please include "Fixes #266" so that issue is automatically closed when the commit is merged into master. See https://help.github.com/articles/closing-issues-via-commit-messages/ for more on how that works.

2. Ideally some short message about why the key is being switched (are there particular API functions the enterprise key gives us or just a higher usage quota, and if so what is that new higher limit? -- it's good to record this somewhere so we keep track of what our expected limits are).

   See this document for details on what makes good commit messages: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

   I'm trying to be a stickler about this stuff so we keep a higher bus factor and don't forget things over time.

3. To make Pull Requests easy to review, the branch you're requesting to be merged should have just the commits related to the issue you're addressing. To clean your branch before submitting a PR, here are three ways to do it.

   Option 1: Just always start from master and only work on one issue per branch.

   git checkout master #go to master to start new branch
   git checkout -b fixes/97-bottles-of-beer-on-the-wall
   git add beer1.txt beer2.txt; git commit
   
   git checkout master #starting at master again
   git checkout -b fixes/100-too-much-beer
   git rm fosters.txt chang.txt coors.txt; git commit

   Option 2: Use git rebase to clean up a commit

   git checkout master #go to master to start new branch
   git checkout -b fixes/97-bottles-of-beer-on-the-wall
   git add beer1.txt beer2.txt; git commit
   git rm fosters.txt chang.txt coors.txt; git commit
   # oh right we need a new branch with just removing beer, not adding, so create branch and rebase:
   
   git checkout -b fixes/100-too-much-beer
   git rebase -i master #rewrite history between master and this new branch
   # rebase opens text editor that looks like this:
   
   pick 20f103c added beer1, beer2
   pick fb9a7cd removed chang, coors, fosters
   
   # Rebase 8fba39d..fb9a7cd onto 8fba39d (2 command(s))
   #
   # Commands:
   # p, pick = use commit
   # r, reword = use commit, but edit the commit message
   # e, edit = use commit, but stop for amending
   # s, squash = use commit, but meld into previous commit
   # f, fixup = like "squash", but discard this commit's log message
   # x, exec = run command (the rest of the line) using shell
   # d, drop = remove commit
   #
   # These lines can be re-ordered; they are executed from top to bottom.
   #
   # If you remove a line here THAT COMMIT WILL BE LOST.
   #
   # However, if you remove everything, the rebase will be aborted.
   #
   # Note that empty commits are commented out
   
   since this branch is all about removing beer, we remove the commit that added beer (just change "pick" to "drop" on first line:
   
   drop 20f103c added beer1, beer2
   pick fb9a7cd removed chang, coors, fosters
   
   # Rebase 8fba39d..fb9a7cd onto 8fba39d (2 command(s))
   #
   # Commands:
   ...
   
   # save the file. Rebase will remove the commit we're dropping, so `git log` will show that the only new commit is removing beer. 

   Option 3: Use git cherry-pick to copy a commit from one branch (e.g. a work branch with tons of commits) into a fresh new branch.

    git checkout master #go to master to start new branch
    git checkout -b fixes/97-bottles-of-beer-on-the-wall
    git add beer1.txt beer2.txt; git commit
    git rm fosters.txt chang.txt coors.txt; git commit
    # oh right we want that last commit on it's own branch
   
    git checkout master
    git checkout -b fixes/100-too-much-beer
    git log fixes/97-bottles-of-beer-on-the-wall #let's see what commits are over there, output is:
   
    fb9a7cd removed chang, coors, fosters
    20f103c added beer1, beer2
    123xyz some last commit on master branch
    ...
   
    # since the too-much-beer branch is starting from a fresh copy of master, 
    # we just cherry pick the one commit we want here
    git cherry-pick fb9a7cd  # copies commit "removed chang, coors, fosters" onto too-much-beer branch

[reekypete]

Apologies for any clutter in my commits. I guess I still am struggling with the conceptual problem of how to chain commits. I'll read through your examples and try to understand :)

[reekypete]

Hmmm - should I just make a fresh branch for the Google license key issue?

[techieshark]

@reekypete fresh branch would be fine.

Should be something like:

git checkout master
git checkout -b fixes/266-new-google-key-cleaned
git cherry-pick 9034529
git push

[techieshark]

This has been taken care of by #277