0

I need to switch to an older commit to check an older functionality of our program that has been later removed.

For that I checkout the corresponding commit:

git checkout 367af0345d0b09ab3ade1c7856462f68e5eafe86

Then I change some code about this deprecated functionality. But this is just for checking I want to ignore all of them.

Now the verification is done I want to come back to the latest working code:

git checkout master

But unfortunately I get a warning that sounds bad:

git checkout master
Checking out files: 100% (281/281), done.
Warning: you are leaving 183 commits behind, not connected to
any of your branches:

  367af03 message
  e5eee29 message
  6999d77 message
 ... and 179 more.

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch new_branch_name 367af0345d0b09ab3ade1c7856462f68e5eafe86

Switched to branch 'master'

Indeed I want to keep the last 183 commits but I don't want to create a new branch, just come back to the state I was before reverting temporarily...

The thing is that now these 183 commits are actually present in my code so they have not been lost like the warning suggests.

What did I miss?

Zoe
  • 27,060
  • 21
  • 118
  • 148
myoan
  • 401
  • 5
  • 14
  • (1) how did you come up with `367af0345d0b09ab3ade1c7856462f68e5eafe86` in the first place? (2) if you try `git branch --contains 367af0345d0b09ab3ade1c7856462f68e5eafe86` and `git tag --contains 367af0345d0b09ab3ade1c7856462f68e5eafe86`, do either one print something? The warning means that at least the `branch --contains` output must be empty... – torek Aug 25 '14 at 09:59
  • I came up with this commit hash graphically on github. The two git branch `return `* master` and the git tag output is empty. – myoan Aug 25 '14 at 13:17
  • That's odd then: if `367af03...` is contained in `master`, `git checkout` should not have complained, and should just have said that it was moving to `master` and that the previous HEAD was detached at that SHA-1. – torek Aug 25 '14 at 17:57

1 Answers1

0

You checked out a revision and git surely told you:

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

Then, you did some commits in this detached HEAD state which are not present on any branch.

Then, you checked out master again leaving these commits behind.

What to do depends on what you need:

  • If you just wanted to check something, then everything is fine. The dangling commits will be cleaned up by git gc
  • If you need the commits (e.g. if 367af0 points to a released version of your software and you are creating a fix for this old release), then you should do what git tells you: check out a new branch that holds these fixes

For the future, if you just want to play around on a certain revision, directly after git checkout <REVISION>, do a git checkout -b tmp_playing_around or something like that in order to avoid the problem with the detached head state.

eckes
  • 64,417
  • 29
  • 168
  • 201
  • Mmmmh after checkouting the detached HEAD I brought some modifications to the code but did not commit anything. What I did, according to my history, is stashing and commiting some stuff without pushing the changes to the server and **only after that** checkouted the detached HEAD. Could it be the reason I got this? – myoan Aug 25 '14 at 13:26