By default, ensure any link generated should be remotely accessible

[keevan]

If the code is somehow detected as not being remotely available then it should prompt the user to push the code so that it is. If this code should already be available, then git-link needs to correctly identify the appropriate commit hash to use, and adjust line numbers as needed.

• Perhaps these extra sets of checks should be an option, since they will do more checks, and potentially slow down link generation, with the benefit of having more reliable/available links.

New uncommitted code:

• If you try and link something that doesn't exist yet (because it's not commited), git-link should tell you. Because even if the link is created based on the commit hash, it won't actually exist yet. I think it's good to inform the user that they need to commit (and optionally push it).

Edge case-ish:

• If you link something that has been committed, but only exists locally (as far as git-link knows about it), it should still copy the link for you but show a warning notification instead perhaps - including the reasoning - something along the lines of "Link to referenced code does not exist remotely". This might be a bit edge case-y, and usually is something the developer should be aware of if needing to link to, so perhaps this isn't actually needed. The warning would still be nice though if possible. But the suggestion would be to just push the code so it's available remotely. This may cross a bit into the next point.

Historical references:

• Currently, if you link something that does exist, but it was committed in the past, it's currently using the current commit hash to reference it. This commit hash, might not exist remotely yet so it won't even work. Proposed solution is to use the latest commit available remotely, for the relevant selection. This may mean the selection won't line up 1:1 with the line numbers (e.g. if new things were added since on prior lines), so having a way to auto-correct this would be good too. A typical workflow might be, fork repo, checkout to appropriate branch, create new branch for development, make changes, reference line in workspace that existed there prior to changes made. Normally, I'd would think, "just push the branch and reference the issue since it's now available remotely" which might work, but for unchanged files and needing to get a quick link, this might be unnecessary. If there was a more elegant approach here it would be good.

Excerpt from PR:

For blame option, it's probably worth checking if the current selection's is a new change or has been committed, and whether that commit has been pushed to the remote.
It should fall back to something like this order, checking whether or not it has been pushed yet:

• latest commit for file, otherwise
• branch, otherwise,
• latest pushed commit for file.

Feels like there should be something that can verify this, whether it's an API call of some sort.

Additionally, sane/smart default behaviour - if you have a selection, and the selection in its entirety doesn't exist anywhere remote yet - then just respond with an error. Don't try and craft the link anyways? Edge case would be when you want a perma link in advance.. 😄 (probably YAGNI) - maybe have an option for "technically correct" even if it would fail normally - for any options falling into this category.