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

Projects
None yet
5 participants
@rgaiacs
Contributor

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
Change commands to be more precise
$ 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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

maxim-belkin commented Jun 8, 2017

HEAD points specific commits only in a detached 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 is applicable to any situation: whether you're on a branch master or not, whether you're in a detached state or not...

@atz

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment