Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change commands to be more precise #328

Open
wants to merge 1 commit into
base: gh-pages
from

Conversation

@rgaiacs
Copy link
Contributor

@rgaiacs rgaiacs commented Aug 27, 2016

$ 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
$ 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
Copy link
Contributor

@daisieh daisieh commented Feb 9, 2017

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
Copy link
Contributor

@maxim-belkin maxim-belkin commented Jun 8, 2017

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
Copy link
Contributor

@atz atz commented Aug 8, 2017

@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
Copy link
Contributor

@maxim-belkin maxim-belkin commented Aug 9, 2017

@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
Copy link
Member

@munkm munkm commented Jan 22, 2019

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")
fmichonneau pushed a commit to fmichonneau/git-novice that referenced this pull request May 28, 2019
fix survey link variables
@kekoziar
Copy link
Contributor

@kekoziar kekoziar commented Jul 3, 2019

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
Copy link
Contributor

@maxim-belkin maxim-belkin commented Jul 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants