On Tue, Apr 29, 2014 at 01:17:49PM -0700, Dani Traphagen wrote:
> I understand how that might be the case @jiffyclub but as it's a
> part of the work flow (especially for remote learners) shouldn't it
> be explicitly described? I understand that this is previously
> described in detail but it seems to me that we should "practice what
> we preach"?

I'm fine with explicitly mentioning it in the text in an aside
(e.g. “Remember, you can always use `git status` if you want to know
what Git's thinking.”).  However, I think scattering too many `git
status` reminders may be confusing (“what if I forget to call `git
status`?) and it dilutes the new branching content with old stuff.
Personally, I have:

  git log --graph --topo-order --oneline --decorate

aliased as `git glog`, and I use that *all the time*.  However, it's
going to be really hard to pick out the new branch-specific push from:

  git log --graph --topo-order --oneline --decorate
  git status
  git add shelter.txt
  git diff --cached
  git status
  git commit
  git status
  git log --graph --topo-order --oneline --decorate
  git push origin shelter_plan
  git log --graph --topo-order --oneline --decorate

which is probably close to my actual workflow ;).  It's easier to
establish good fundamentals for inspection and commit creation, and
then tell them: “Create a new commit like you normally do:

  git add shelter.txt
  git commit

But push the new branch upstream (instead of pushing your master
branch):

  git push origin shelter_plan

You can verify the push with something like:

  git log --graph --topo-order --oneline --decorate

yada yada…”