0

I have situation like this: on branch design-decisions.

Latest commits:

Design Option 2
Design Option 1

I want to checkout commit 'Design Option 1' and use it to create commit 'Design Option 3'. I don't want to lose or modify commits 'Design Option 1' or 'Design Option 2'.

I know that I can check out commit Design Option 1 with this command:

git checkout HEAD~1

Then I get this message: "You are in 'detached HEAD' state."

That's not really helpful as I don't understand what's the big deal with detached HEAD.

Why can't I just work like usual from detached head? Why won't this work?

// Make changes
git add .
git commit -m "Design Option 3"
git push

I would prefer not to create new branch and just tell git shut up and create new commit from this detached head state without merging stuff and so on.

How to make it work?

Marko-A
  • 17
  • 3
  • And once you checkout another branch, how do you think you'll access the commit you added on top of the detached head? – chepner Apr 20 '15 at 14:53
  • What I really want is for that commit to be added after head. Something like git commit -hm "Message" where -h means add this commit as if head was not detached as last commit on this branch. – Marko-A Apr 20 '15 at 16:56
  • `HEAD` in Git is just a symbolic reference to a branch; adding a commit to a detached head makes it unreachable from any other branch. When you say "add this commit ... on this branch", there *is* no "this branch" when you have a detached head. – chepner Apr 20 '15 at 17:28

3 Answers3

4

Why can't I just work like usual from detached head? Why won't this work?

Because the push won't know what to push (which commit, and to which branch on the remote side).
See "Why did my Git repo enter a detached HEAD state?".

It is best to create a new branch, work on it and push it.

git checkout -b newBranch HEAD~1
# work
# Make changes
git add .
git commit -m "Design Option 3"
git push -u origin newBranch
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

When you try to work against a system/ software/ whatever, you will have a hard time. Git is no exception. Branches are the solution to your problem and they are cheap (some hundred bytes? less?) So: just use them.

Peter Schneider
  • 1,683
  • 12
  • 31
0

Checkout files from a commit like this

git checkout HEAD~1 -- .

Makes the command checkout files from HEAD~1 and puts these in the index. It will not cause detached head state. git checkout can checkout commits and branches, but also files. If checking out files from a specific commit one need to distinguish files and commits with the --, commit before and files after (in this case . represents all files in current directory)

But solution to your problem is really using branches for the different designs

Joakim Elofsson
  • 36,326
  • 1
  • 22
  • 28
  • What does -- stand for? What does . stand for? What does that command do? – Marko-A Apr 20 '15 at 15:02
  • -- separates refs/commits/branches from files, the . says 'all files' in current directory – Joakim Elofsson Apr 20 '15 at 15:06
  • I don't understand this part "-- separates refs/commits/branches from files". Do you mean if you want to specify commit and files in same command you have to separate it with --? Also how is that different from what I wrote? `git checkout HEAD~1`? Are you saying that your command won't create detached head? – Marko-A Apr 20 '15 at 17:04