Change commands to be more precise

[rgaiacs]

$ git checkout HEAD file

and

$ git checkout master file

will produce the same result when HEAD and master point to the same commit
but will produce different results when HEAD and master point to different commits.

To make the text more precise and compatible with "last saved commit"
we suggested learners to use

$ git checkout master file

[daisieh]

Don't we spend a lot of time talking about how to use HEAD and the HEAD~x references to move around, but very little time on master?

[maxim-belkin]

HEAD points to a specific commit only in the so-called detached-head state. Naturally, HEAD points to branches (such as master). Because branches are not touched in this lesson, I think it is better to continue to use HEAD. Moreover, git checkout HEAD file is applicable to any situation: whether you're on a branch master or not, whether you're in a detached state or not...

[atz]

@maxim-belkin, I disagree. Because branches are not touched in this lesson, it is better to provide the command that will not betray the learner's expectations when they (almost inevitably) do encounter branches. The meaning of master is clearer than HEAD and suggests other branch arguments that could be used in its place. The flexibility of that argument (and not just enumerating ~1, ~2 suffixes) is important.

It might be worthwhile to also show that one can do git checkout and git show with:

• master, master~1, master~2, etc.
• [HASH], [HASH]~1, [HASH]~2, etc.
• HEAD, HEAD~1, HEAD~2, etc.

And clarify when those are synonymous and when they aren't (implied: branches matter). A more robust presentation would spend time fleshing out the concept of a refspec.

In general, I find we are at odds with the fundamental operation of any DVCS by pushing branching out of scope.

[maxim-belkin]

@atz, which statement specifically do you disagree with?

Note: I always try to talk about branches (they are very important in my view). Introducing refs might be too much for a half-day lesson though. And definitely too much for new gitters

[munkm]

What if we used the same command that's suggested by git to discard changes in the working directory (which we can emphasize goes back to the "most recent snapshot"), e.g. git checkout -- <file> ?

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

[kekoziar]

HEAD is a pointer to the most recent commit on a branch. master is a branch. They are two different things. I think because the episode goes on to recover the file from previous commits, using HEAD is most appropriate here since it is analogous to the most recent commit.

[maxim-belkin]

The best definition for HEAD is "parent of the next commit". With that in mind, I too vote for continuing to use HEAD

[kekoziar]

Closing because PR is stale. Also, recent changes show why we should keep using HEAD instead of a name of a branch, which might change.