Support for detached HEAD state?

[IDG SERPRO]

If you're in a detached HEAD state, ${2:-$(git symbolic-ref -q --short HEAD)} gives nothing.

If you use git symbolic-ref HEAD and it fails with fatal: ref HEAD is not a symbolic ref, you're in a detached HEAD.

Being in this state, git status gives you, for example, HEAD detached at 1.1b1. You can extract the tag/branch/commit after HEAD detached at and complement the https://github.com/ORG/REPO/tree/EXTRACTED and be able to open repositories in detached HEAD. It worked with the short hash.

...or if you're into an even more pragmatic approach, do an if grep -v 'HEAD detached'; then and extract the hash. :)

More info about detached HEAD: https://stackoverflow.com/a/5772882

[Paul Irish]

sure..

so to repro:

# in the git-open repo
git checkout a8a9f96eba77ac5c97e18e543395d5f28da61a34
env BROWSER='echo' git-open
# https://github.com/paulirish/git-open/tree/

what are you expecting here? would we open:

1. the repo's home (default branch)
2. the details for this specific commit (basically the diff)
3. the repo tree at this specific commit

TBH i feel like all 3 are somewhat reasonable. :/

[Dave Wikoff]

I think 3 makes the most sense, 2 seems like a new feature that if implemented i don't think should be limited to detached heads. The reason I go with 3 is because in terms of what I would expect as a user it's consistent with being on a branch, except the git rev is the hash instead of the branch name. But I am not in detached state much often so I'd be curious to what @idgserpro thinks

[IDG SERPRO]

the repo tree at this specific commit

That's the idea.

[Paul Irish]

groovy. sgtm.

@idgserpro are you interested in writing the tests for this feature? just collecting the URL formats would be hugely useful..

[IDG SERPRO]

I'm not familiar with bats, I will need some time.

When you say "Url formats" are you talking about GitHub, GitLab, Bitbucket?

[Paul Irish]

When you say "Url formats" are you talking about GitHub, GitLab, Bitbucket?

yup.