git/novice/01-backup.md: Diffs are for people too

If diffs were not intended for human consumption, I'd expect they
would be printed in a binary format.  If you want a format that's
almost exactly like Microsoft Word's "track changes" feature, you can
use `--word-diff=color`.  For code, the default format is probably
more legible.  Also, the colorized output (we configured color.ui
earlier) may help a bit.  Can we colorize the Markdown preformatted
block?

In any case, I think the tone we're shooting for is "don't worry if
you don't understand the diff yet, we're about to explain it", not
"you might as well give up now, this is only for wizards" ;).
01-backup.md: Don't go into detail about diff's index line

I've only ever seen it used on the Git mailing list to ask if a patch
was based on unpublished work, but digging that reference out of the
mailing list archives would be difficult.  Newbies probably don't care
about the information encoded in that line.
git/novice/01-backup.md: Mark diff's `+` as code

That's what we use for `@@`, and we should be consistent.  Code
styling should also match the preformatted-block styling used for the
diff itself, and it's nice if the styling of our reference matches the
styling of the original.
git/novice/01-backup.md: Remove split-file argument

I don't find this argument very convincing.  I rarely have to reset a
particular program class or document section to an earlier revision.
I *do* have to undo broken commits, but there you have `git rebase` or
`git revert` to help you out.  Without that use case to motivate it, I
think "you'll probably want to restructure your workflow to use lots
of tiny files" is too aggressive for new Git users.
git/novice/02-collab.md: Reword 'move' -> 'share'

Move implies a single copy switching from one place to another.  In
other words, the original location no longer has the moved item after
the move.  Version control systems usually copy between repositories,
adding the item to the new location without removing it from the
original location.

I also changed the item from 'files' to 'changes', because although
for Git, both blobs and commits are copied.  To me, 'changes' implies
the broader scope (current status, as well as why and how we got
there), while 'files' just implies the current status.
git/novice/02-collab.md: Link to Pro Git's distributed workflows

For folks to see some other options.  I can't cite statistics, but
even Software Carpentry is moving away from the centralized repo
workflow.  Every other project I'm involved with (outside of my job)
uses the 'integration manager' workflow.  I think it's best to soften
statements like "it's easiest" and "most programmers" and instead just
say we're going to show them a popular approach, while linking to a
number of other popular approaches.
git/novice/02-collab.md: 'http identifier' -> 'http protocol'

Git calls them protocols in the 'GIT URLS' section of git-fetch(1).
No need to use our own name.  Hopefully not too many people mind the
'Hypertext Transfer Protocol protocol' redundancy ;).
git/novice/02-collab.md: Change 'string' -> 'URL'

In 2013, even novice Git users should have heard the term 'URL' a few
times before they get into our class.
git/novice/02-collab.md: Remove references to 'push -u'

I don't think the distinction between:

  $ git push -u nickname master

and

  $ git push nicname master

is useful for newbies.  The former is explained as "Push changes from
a local repository to a remote (if master doesn't yet exist in the
remote)", but that's not what the -u option actually does (it actually
sets the upstream branch, see git push --help for details). I only use
-u myself when I'm setting up a branch for a hub pull-request [1,2].

I'm not sure we should be teaching the more implicit forms of push,
because the default semantics are going to change with Git 2.0 [3].  I
imagine that will lead to confusion if students are referring to notes
that haven't been future-proofed by either:

a. explaining the change in push semantics, or
b. only using explicit forms (`git push $REMOTE $BRANCH`)

In the interest of simplicity (and following PEP 20 [4]), I'm in favor
of option b.  Then students don't need to internalize the default
remote- and branch-selection rules.

If we go with (b), I don't see why we'd care about the default
upstream branch.  Perhaps we want 'git status' to explain:

  # Your branch is ahead of 'origin/master' by 14 commits.

or some such.  If so, I think that we should explicitly use that in
our motivation.

[1]: https://github.com/github/hub#contributing
[2]: https://github.com/github/hub/blob/master/lib/hub/commands.rb#L179
[3]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/1.8.5.txt#n7
[4]: http://www.python.org/dev/peps/pep-0020/
git/novice/03-conflict.md: Reword non-fast-forward push explanation

Git would complain that 'tip of your current branch is behind hint:
its remote counterpart' event if the changes didn't overlap.  The
problem is that the push isn't a fast forward, not that there are
merge conflicts.
git/novice: Standardize on github.com/vlad/ (not /gvwilson/)

We added the remote as 'vlad' in 02-collab.md.  I expect the
'gvwilson' entries are just copy/paste errors.
git/novice/03-conflict.md: Replace small-files with communication

For explaining conflict avoidance.  The size of your file doesn't
really matter to Git (outside of the three lines of diff context, it
doesn't care at all).  Communication is important, and separate files
may help you do that, but there are other ways to avoid stepping on
toes as well (including shouting "I'm about to refactor fizz_buzz(),
do you have any pending changes I should know about first?" across the
hallway).
04-open.md: Mention Bitbucket's free private repositories

From the current https://bitbucket.org/plans:

  All plans include:
  * Unlimited private repos
  ...

I think the main reason to use common hosting sites like GitHub and
Bitbucket is increased visibility or access to features (like the web
interface and bug trackers).

Personally, I wouldn't trust a third party host to protect my private
data when I can easily host it myself.  I'm not sure how widely shared
this paranoia is ;), but I'd certainly want to talk to lawyers before
hosting patient medical records in a private repository on Bitbucket.