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

Prefer SHA to branch, give option to right-click in editor, and prefer line numbers #78

Merged
merged 1 commit into from Feb 5, 2018

Conversation

Projects
None yet
3 participants
@martynchamberlin
Contributor

martynchamberlin commented Dec 17, 2017

Summary

This PR introduces 3 changes:

  1. It prefers SHAs to branches when building the URL with which to open on GitHub.
  2. It gives the option to open on GitHub on the context menu in the editor, not just in the explorer.
  3. It gives preference to line numbers in this latter context.

Explanation

I'm a recovering PHPStorm user, and I've been enjoying VSCode for a couple of weeks now. For all of its problems, PHPStorm had something amazing that I've been missing in VSCode. It had GitHub integration out of the box, and among the other things you could do, you could right-click directly in the editor, open the current file on GitHub, and it would go to your SHA, not your branch name, as ziyasal/vscode-open-in-github currently does.

I want to explain why opening to the SHA is more helpful than branch name (for clarity, it's the difference between an URL like this and one like this). Very often, I'll check out a new branch to start work on something. As I begin to explore the problem, I realize that I need to have a conversation with another developer on the team about the best way to approach a problem. My company works remote and uses Slack, so this means sharing GitHub links. Unless I push an empty branch to GitHub, then the resulting link is a 404. Pushing an empty branch is annoying, because nobody wants to have to push something to GitHub until they have a dirty working tree and an actual change to commit. Otherwise they risk having empty unused branches on GitHub that they then have to clean up in the future. It's not an enjoyable workflow. SHAs, on the other hand, are not 404s, because the SHA for a given file does not change from one branch to the next, so long as that file has not been changed.

Granted, this cuts both ways. If you push a branch to GitHub, make some more changes locally, commit them, but don't push the commit, and then right-click and "Open on GitHub" and that triggers a branch-based URL opening in your browser, you'll get a 200, but if it triggers a SHA-based URL, you'll get a 404. However, I think it's fair to say that this is a much less common scenario, and in that case, you can simply git push to fix that problem; since you have a local commit that's not on GitHub, you'll want to push that eventually anyway and it feels good, in a way that pushing an empty branch does not.

There's a second reason that opening to the SHA is more valuable than a branch, and that is this. When you share a branch-based GitHub link, it's almost never because you're wanting to call attention to that branch as that branch but rather, you're calling attention to a file in its current state. For example, if I link to line 37 of a branch named MC/hotfix, I probably want that link to be exactly the same if it is referenced today or a week from now; if a future commit in that branch adds lines prior to line 37, causing the line to get bumped to 42, then line 37 won't be correct if the link is branch-based, but it will be correct if it's SHA-based. I can't tell you how many times I've looked at a repo where a branch-based link was given that should have been SHA based. The link no longer worked because the branch had been removed or the file had been so severely altered since then that it no longer made sense. My only recourse in such a scenario is to get the timeframe of when the link was inserted, and then view the overall repo's state at that timeframe. This is a mess that can be completely avoided if developers simply used the SHA instead of the branch. GitHub never deletes SHAs. Even SHAs that are no longer connected to any existing branch and consequently no longer tied to any history remain on GitHub's servers indefinitely.

I'm opening this PR to begin some discussion. I doubt the code in its current form can be merged per se. I imagine we'll want to create a user setting so the user can switch between branch and SHA (though I'd love to default to SHA, because I truly believe from my reasons above that it's the superior method for most developers most of the time). Regardless, I've created a VSIX of this clone and it's the version of this extension that I'm using locally for now.

@spalladino

This comment has been minimized.

Show comment
Hide comment
@spalladino

spalladino Dec 20, 2017

It prefers SHAs to branches when building the URL with which to open on GitHub.

This is exactly what I'd need. Are there plans to accept this PR from the maintainers? Thanks!

spalladino commented Dec 20, 2017

It prefers SHAs to branches when building the URL with which to open on GitHub.

This is exactly what I'd need. Are there plans to accept this PR from the maintainers? Thanks!

@ziyasal ziyasal merged commit 9b1a86f into ziyasal:master Feb 5, 2018

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment