1

On a case-insensitive file system, I can reference head in git commands and it works like HEAD.

git rebase -i head~4

On a case-sensitive system, I have to reference HEAD exactly.

git rebase -i HEAD~4

I miss the ease with which my fingers can spit out head without reaching for Shift, and I reference HEAD frequently enough that I'd like to alias head to it.

I found a way to do this, but it has a couple drawbacks.

git symbolic-ref head HEAD

I'd have to manually set this up in each repo (though maybe there's a way I can use templates to do it automatically upon git init).

I also don't understand some of the git symbolic-ref behavior. For example, I can create an arbitrary alias to a ref,

$ git log -1 my-feature 5bb7f1e add new feature $ git symbolic-ref foo my-feature $ git log -1 foo 5bb7f1e add new feature

And according to the git-symbolic-ref man page, I can also delete the symbolic-ref, but I can't get that to work:

$ git symbolic-ref --delete foo error: refusing to update ref with bad name 'foo'

What am I misunderstanding about symbolic-refs? Is this a bad way to use them?

Update

If I create the head ref as:

git symbolic-ref --delete "refs/heads/head"

then it lives in .git/refs/heads/head (rather than .git/head as it did in my original attempt). I can still reference it as head,

git log -1 head

and symbolic-ref updates/deletes work as expected

git symbolic-ref --delete refs/heads/head
Improve this question
1
  • 1
    Basically, symbolic refs don't quite work right. They act like symlinks (unsurprising, since HEAD was originally actually a symlink!). To delete one that's not under refs/, through Git commands, you can use git update-ref -d. Commented Feb 15, 2018 at 18:34

1 Answer 1

Reset to default
2

Just use the existing @ synonym, git log @{-1} to show your recent checkout's history will be faster than git log head@{-1}, git show @~ to show your worktree's gp commit faster than git show head~.

The spotty rejection of refnames not starting refs/ is I think an artifact, git uses such refnames internally but they're like reserved names in programming languages, any time you get away with using one for your own purposes you're living in a state of sin.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

While the @ synonym is nice to know about (thanks for that), I still find head easier+faster to type (no Shift chord, no reaching for the number row). Maybe surprising, since I'll be reaching up around that area for the ~ anyway, but I can type head without thinking about it and then I'm free to focus on ~4 or whatever. On the other note, I still can't get git symbolic-ref --delete to work with any variation on the symbolic-ref name or its contents, even if the contents look like ref: refs/heads/my-feature.
It's not the contents, it's the refname itself. names outside the refs/ hierarchy are for internal use, as I say the rejection of those is spotty, git doesn't want to make it impossible to use them, just annoying enough to get you to reconsider. To delete the ref named head, delete .git/head or if you've done a git pack-refs --all that won't exist, edit the lines out of .git/packed-refs
Thanks for clarifying. That helped me realize I could create my ref as refs/heads/head and get the behavior I expected.
That's a good idea, but make it a tag, git symbolic-ref refs/tags/head HEAD. Making it a branch will cause git checkout to "attach" HEAD to it, to making HEAD a symbolic ref to it so when git commit updates HEAD the ref redirects the update to the branch tip.
Ah, good call. I tried it out, checking out head as a branch, adding something, then attempting git commit, and got: fatal: multiple updates for 'HEAD' (including one via symref 'refs/heads/head') are not allowed. Changing it to a tag works better.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.