Use rev-parse to get HEAD.

[shioyama]

git show-ref seems to use the origin's HEAD rather than the local one. git rev-parse HEAD consistently gives the local head.

[tonchis]

@shioyama You're right, git show-ref HEAD picks up refs/remotes/origin/HEAD's sha.

But suppose I'm working locally, commit but don't push to GitHub. Using git rev-parse HEAD would get my latest commit and the :ToGithub link would result in a 404, since it'd point to a commit that GitHub doesn't know about.

I'm not sure this is the behavior we're looking for, but what motive you see to pick the latest local commit instead of the latest remote commit?

[shioyama]

Ah ok, well the problem I had was that it if you're on a different branch, it still picks the remote head, when what I would expect would be the (remote or local) ref for the branch I'm currently on. Maybe we can figure out how to do that instead.

[tonchis]

@shioyama I've been thinking about this. The problem you're experiencing comes from #10, which I think is a step forward because linking to commits it's much more useful than linking to branches (in the latest remote commit).

With this in mind I think that if :ToGithub gives you a link to a commit but you haven't pushed yet, it's ok to see a 404, because the commit exists, but GitHub doesn't know about it yet.

I also prefer this over trying to be smart about which commit should we select (depending on what's pushed, which branch is HEAD on, etc). It's simpler and a 404 explains itself.

I will add a "Caveats" section in the README to warn about it in this PR and then merge.

Thank you for spotting this :)

[shioyama]

@tonchis yes I agree. I think if you jump to github on a commit that has not been pushed, it would be stranger for ToGithub to find the closest commit on the remote. Most likely that commit would have different content from what you were actually looking at, so a 404 is more appropriate.

Thanks for merging!