Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get permalinks for the local HEAD not the HEAD of the remote branch #119

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wearhere
Copy link
Contributor

@wearhere wearhere commented Jul 18, 2019

On GitHub, permalinks reference the HEAD of the remote branch since that’s
what you’re looking at when you request the permalink
(https://help.github.com/en/articles/getting-permanent-links-to-files). In
Sublime, it makes more sense for permalinks to reference your local HEAD
since that’s what you’re looking at when you run a permalink command.

Referencing the local HEAD lets the user run permalink commands with a
commit checked out rather than a branch; or having checked out a branch that
they've just created, if the user has neither added commits to that branch nor
pushed the branch to the remote.

If the user has added commits to such a branch without pushing them to the
remote, then the link will 404 on GitHub. Then again, previously, if the user
had pushed the branch to the remote—just not the most recent commits on
the branch—then we would have created an out-of-date permalink, and this would arguably have been a worse failure because it would be silent.

At some future point, it might be nice to detect, locally, if a permalink was
going to 404, and show an error message before the user went to GitHub.

Referencing the local HEAD also fixes a bug in the previous implementation
where we’d only successfully fetch the remote HEAD if the name of the remote
branch was exactly the same as the local branch, since we executed
git rev-parse <remote_branch> at line 508 without prefixing
remote_branch with the name of the remote.

Tests:

  • “Open Remote URL in Browser” works if the current branch has been
    pushed to the remote
  • “Open Remote URL in Browser” shows an error alert if the current branch
    has not been pushed to the remote
  • “Open Remote URL in Browser” shows an error alert if a commit is
    checked out rather than a branch
  • “Open Remote URL in Browser (permalink)” works if the current branch
    has been pushed to the remote
  • “Open Remote URL in Browser (permalink)” works if a commit is checked
    out vs. a branch
  • “Open Remote URL in Browser (permalink)” works if a branch is checked
    out and the user has not pushed that branch but has also not added commits
    to that branch
  • “Open Remote URL in Browser (permalink)” results in a 404 on GitHub
    if the user has added commits to a branch and not pushed them to GitHub
  • “Open Remote URL in Browser (permalink)” shows an error alert if the user has not pushed their local branch and has more than one remote configured
  • “Open Remote URL in Browser (master)” works regardless of what’s checked out above

On GitHub, permalinks reference the HEAD of the remote branch since that’s
what you’re looking at when you request the permalink
(https://help.github.com/en/articles/getting-permanent-links-to-files). In
Sublime, it makes more sense for permalinks to reference your local HEAD
since _that’s_ what you’re looking at when you run a permalink command.

Referencing the local HEAD lets the user run permalink commands with a
commit checked out rather than a branch; or having checked out a branch that
they've just created, if the user has neither added commits to that branch nor
pushed the branch to the remote.

If the user _has_ added commits to such a branch without pushing them to the
remote, then the link will 404 on GitHub. Then again, previously, if the user
had pushed the branch to the remote—just not the most recent commits on
the branch—then we would have created an out-of-date permalink, and this would arguably have been a worse failure because it would be silent.

At some future point, it might be nice to detect, locally, if a permalink was
going to 404, and show an error message before the user went to GitHub.

Referencing the local HEAD also fixes a bug in the previous implementation
where we’d only successfully fetch the remote HEAD if the name of the remote
branch was exactly the same as the local branch, since we executed
`git rev-parse <remote_branch>` at line 508 without prefixing
`remote_branch` with the name of the remote.

Tests:
- [x] “Open Remote URL in Browser” works if the current branch has been
  pushed to the remote
- [x] “Open Remote URL in Browser” shows an error alert if the current branch
  has not been pushed to the remote
- [x] “Open Remote URL in Browser” shows an error alert if a commit is
  checked out rather than a branch
- [x] “Open Remote URL in Browser (permalink)” works if the current branch
  has been pushed to the remote
- [x] “Open Remote URL in Browser (permalink)” works if a commit is checked
  out vs. a branch
- [x] “Open Remote URL in Browser (permalink)” works if a branch is checked
  out and the user has not pushed that branch but has also not added commits
  to that branch
- [x] “Open Remote URL in Browser (permalink)” results in a 404 on GitHub
  if the user has added commits to a branch and not pushed them to GitHub
- [x] “Open Remote URL in Browser (master)” works regardless of what’s checked out above
@wearhere wearhere marked this pull request as ready for review July 18, 2019 00:57
@bgreenlee
Copy link
Owner

Hi! I'm so sorry it has taken me years to respond to you. If you're still interested in this would you mind testing it again against the latest HEAD and fixing the minor conflict in the README?

(I know I've neglected this repo...I haven't used Sublime Text in years. :( )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants