0

I have two tags on a branch. Whenever I do git reset old_tag it changes the head to the old_tag and says that I'm behind by 1 commit (which is expected). However, git checkout old_tag gives a detached head.

As far as I understand, git reset only changes the head pointer. As for git checkout I use it always to switch branches or checkout a certain commit in a new branch. But I never used it to checkout a commit all by itself without a branch. So, if it will always give a detached head, why is it allowed to checkout a commit by itself in the first place?

Update: The bold part is the difference between my question and the referred duplicate question.

mkmostafa
  • 3,071
  • 2
  • 18
  • 47
  • Why shouldn't it be possible to checkout only a single commit? ;) – ckruczek Aug 27 '15 at 13:08
  • @ckruczek could you explain to me what does checkout actually do? I explained my understanding for it in the post. – mkmostafa Aug 27 '15 at 13:10
  • The git manpage is telling you the following > When `< paths >` or `--patch` are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named `` (most often a commit). – ckruczek Aug 27 '15 at 13:18
  • @ckruczek do u mean by paths "some files"? what is meant by index and working tree? – mkmostafa Aug 27 '15 at 13:23
  • 5
    possible duplicate of [What's the difference between "git reset" and "git checkout"?](http://stackoverflow.com/questions/3639342/whats-the-difference-between-git-reset-and-git-checkout) – jub0bs Aug 27 '15 at 13:24
  • @Jubobs No, that didn't solve my problem. Basically the answer stated what I said, that it will always give a detached head if you didn't checkout in a new branch. So why is that allowed if it's already decided?! – mkmostafa Aug 27 '15 at 13:29
  • 1
    "So, if it will always give a detached head, why is it allowed to checkout a commit by itself in the first place?" I don't get what you're asking here. Are you trying to say that detached heads are useless, and therefore shouldn't be allowed? That's not true; detached heads can be useful in many cases where you don't care about saving changes or just want to experiment with the working directory at a specific commit. – Ajedi32 Aug 27 '15 at 13:29
  • @Ajedi32 Why not just use git reset then? – mkmostafa Aug 27 '15 at 13:31
  • @Ajedi32 I'm not trying to say anything :D ... I'm just trying to understand the mechanism – mkmostafa Aug 27 '15 at 13:32
  • 2
    @mkmostafa Because `reset` resets the current branch, `checkout` does not. (That's explained in the suggested duplicate.) If you're in a detached head state, `checkout` and `reset --hard` can be very similar since there is no "current branch" to reset in the latter case, but that's merely a natural consequence of that one edge case, not an indication of either command being redundant. – Ajedi32 Aug 27 '15 at 13:37
  • 1
    @Ajedi32 So basically it's as follows: git reset will change the head in your branch but if you'd like to keep your current branch as it is and play with an old commit you'd checkout that commit in a detached state instead of having to reset your current branch. Is that correct? – mkmostafa Aug 27 '15 at 13:44
  • 2
    @mkmostafa Correct. Checkout is for switching branches and updating your working directory. Reset is for resetting the current branch to a different commit. – Ajedi32 Aug 27 '15 at 13:47

3 Answers3

0

Sourced form the documentation:

git-checkout - Switch branches or restore working tree files. Or perfecty described as:

Updates files in the working tree to match the version in the index or the specified tree. If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch.

git-reset - Reset current HEAD to the specified state

atw
  • 5,428
  • 10
  • 39
  • 63
  • what is meant by index and working trees in this context? – mkmostafa Aug 27 '15 at 13:22
  • Index is the place where you put files you want committed to the git repository. The working tree is where you do your work. Check this: [Difference between HEAD / Working Tree / Index in Git](http://stackoverflow.com/questions/3689838/difference-between-head-working-tree-index-in-git). – atw Aug 27 '15 at 13:25
0

Based on the discussions in the comments, the following has been reached:

git-reset:

changes the head to different commits/tags... the head could be reset either if you are currently:

  1. on a branch.

  2. detached state.

    But git reset will not get you into a detached state.

git-checkout:

  1. either used to create a branch and checkout a commit in it
  2. switch between branches
  3. get you in a detached state (if you checked out a commit by itself).

The last use was the one concerning my question. Sometimes you'd like not to reset your current branch to experiment with an old commit. But instead get into a detached state with a specific commit and play with that old state. Only get checkout will get you into that state and this can not be achieved through the git reset because it only resets branches (or could reset also if in a detached state) but not get you in a detached state.

mkmostafa
  • 3,071
  • 2
  • 18
  • 47
0

A detached head situation is not common. However, it could be interesting to be sure that you are not going to commit anything.

You cannot get a detached situation with git-reset because what it does is to move your current branch (and maybe your stage area and working directory, depending on the option that you use) where you command.

git-reset is not only moving the HEAD. It moves your branch, HEAD and Staged Area where you command.

You move only the branch and HEAD with:

git reset --soft tag/SHA1/branch2

You move the branch, HEAD and Stage Area with:

git reset --mixed tag/SHA1/branch2 //It is the default option

You move the branch, HEAD, Stage Area and Working directory with:

git reset --hard tag/SHA1/branch2
blashser
  • 921
  • 6
  • 13