1

I'm writing a shell script which switches to a specified commit, makes a copy of the index in /tmp, resets HEAD to original position, then runs a command in the temporary directory:

orig_head=$(git rev-parse -q HEAD)  # "refs/heads/master"
git checkout "$1"
# copy index to /tmp/...
git checkout "$orig_head"
# run command in /tmp/...

However, this script gives me the same "'detached HEAD' state" message as when I run git checkout refs/heads/master:

Note: checking out 'refs/heads/master'.

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

HEAD is now at c82ad67... Use vector and binary search for dictionary

How can I store and restore the position of HEAD properly?

I would prefer to avoid using reset HEAD@{1}, as that seems messy.

Zaz
  • 46,476
  • 14
  • 84
  • 101
  • What happens if you just omit "--symbolic"? With "--symbolic" it seems to return meaningless label "HEAD", which doesn't mean anything after you checkout "$1". I cannot reproduce the behavior where `$(git rev-parse --symbolic -q HEAD)` returns "refs/heads/master", however... – Andrey Tyukin May 02 '15 at 20:08
  • @AndreyTyukin: Thanks, you're right. With `--symbolic` it doesn't work at all, but without `--symbolic` I am getting the message shown above. – Zaz May 02 '15 at 20:13
  • 1
    Interesting, I read it (without thinking too hard) as if it were using `git symbolic-ref` above, which is in fact what one should use (see my answer below). – torek May 02 '15 at 20:15
  • Yeah, weird. Looks like my subconscious was on the right tracks! – Zaz May 02 '15 at 20:36

2 Answers2

2

Most git commands don't really care whether a name is a branch name. The obvious exceptions (there may be more, these are off the top of my head) are git branch and, of course, git checkout.

For the non-exceptions, the rules for resolving branch names to SHA-1s are listed in gitrevisions. For git branch it's easier: some arguments are obviously branch-names, e.g., in git branch new/branch/name, new/branch/name is a branch name, even though it presumably doesn't exist yet.

The checkout command can't do that: given git checkout xyz, xyz might be a branch name, or a tag name, or any of the other forms in gitrevisions. Of course, to be one of the funny syntax forms like HEAD~5 it has to have the special ~ character in it, but even an unadorned name might be a branch name, or might not. (If it follows -b, as in git checkout -b new/branch then is is definitely a branch-name, but that's not the case here.)

Anyway, the short answer is that git checkout has its own special rules, different from those listed in gitrevisions: a name is a branch name if adding refs/heads/ in front works to turn it into an existing branch name.

This fails with refs/heads/master since refs/heads/refs/heads/master is not an existing branch name.1 Hence you need to strip off the refs/heads/ part yourself.

You could do this after-the-fact, but there's an easier version: git symbolic-ref has --short to leave the refs/heads/ part off. Since HEAD should only be a symbolic reference to a branch (never a symbolic ref to a tag for instance), and you know you're inquiring about HEAD, just do:

orig_head=$(git symbolic-ref -q --short HEAD)

You do need one more bit, which is to remember whether the system was in detached HEAD state to start with, and if so, what SHA-1 that goes with. So:

sha1=$(git rev-parse HEAD) || exit 1 # should never fail
orig_head=$(git symbolic-ref -q --short HEAD) && symbolic=true || symbolic=false

or something along those lines.

1You can create such a branch. Don't. :-)

torek
  • 448,244
  • 59
  • 642
  • 775
  • Any reason not to do: `orig_head=$(git symbolic-ref -q --short HEAD || git rev-parse HEAD) || exit 1`? – Zaz May 02 '15 at 20:35
  • It depends on how fancy you want to be. The rebase script, for instance, remembers your original state and branch-name separately so that it can say where you were. If you just need to get back to it, it seems that should do the trick. – torek May 02 '15 at 20:47
-1

master is a kind of pointer which points to the latest commit of master branch.

Whereas refs/heads/master is a kind of history tracker which tracks activities of master pointer like commits,switching to other branch,pushing master branch on github etc.

Faizan Makandar
  • 51
  • 3