I'd prefer to use colon as a separator between branch and file path as Git does.

@hkdobrev I'm not familiar, can you show me?

Also I'd accept suggestions on how to match something like:

const regex = /(?=2)red/; // match 'red' only if it's preceded by 2?
console.log('0red'.replace(regex, 'blue')) // '0red'
console.log('2red'.replace(regex, 'blue')) // '2red' but I want '2blue'

@bfred-it On the final visualisation of the links I recommend the following:

• https://github.com/vendor/repo/blob/master/path/to/file.js -> master:path/to/file.js
• https://github.com/vendor/repo/tree/master/path/to/directory -> master:path/to/directory

Example of Git using such notation: https://stackoverflow.com/a/338470/679227
(will link to official manual when it stops giving 500 error pages)

I think this is good because Git is using : to separate refs and path specs in various cases, but other software like scp is using it as well. Also, the forward slash character / is used for both directory separator and often used in the name of branches in different Git workflows.

On the regex matching:

You're trying to do positive lookbehind which could be achieved with a regex like the following:

/(?<=2)red/

However, positive lookbehind is not supported in the JavaScript regex engine. That's why you'd need to use match groups to extract the text you need. Relevant SO answer: https://stackoverflow.com/a/3569116/679227

E.g. you could use /2([a-z_-\/\+)/ and then use the first matched group.

@hkdobrev how about external repos? Like this? user/not-this-repo/master:index.js

Thanks for the info about regex. I was hoping for a way to avoid the ${repo}/ part here:

  // Shorten and highlight commit hashes
  .replace(/([^/]+\/[^/]+)\/blob\/([\da-f]{7,})/i, (m, repo, hash) => {
  	return `${repo}/<code>${hash.substr(0, 7)}</code>`;
  })

I worked around the regex complexity by using URL parsing and explicit variables. This should be safer and it's also more mindful of external URLs.

Also added raw handling and switched to : after the branch.

Current situation:

But I'm not a fan of how : looks, I prefer the first one:

1. user/repo/branch/.gitignore
2. user/repo/branch:.gitignore

If you use the forward slash it's not so easy to determine where the branch name end and where the filename starts. Here, you have used inline code to distinguish it, but on the command line this is not possible and that's why colon is used. I'd prefer to wrap both the branch and the path to a single inline code element.

The command line does not highlight the branch name like we do though though, so what's necessary there isn't necessary here.

A monospaced filename can get long too. I don't think the filename start gets lost if only the branch is highlighted:

1. user/repo/branch/.gitignore <- similar to the URL: github.com/user/repo/blob/master/.gitignore
2. user/repo/branch:.gitignore <- still not a fan of :.

I'm not a fan of the slash either. What about using @ similar to npm (and GitHub sometimes, e.g. sindresorhus/linkify-urls@aca71b8):

• icon.ai@master
• src/content.js@784a028
• .eslintrc@rollup/rollup/master
• .eslintrc@rollup/rollup/rollup-init
• blame: .editorconfig@patch-diff-shortcuts
• readme.md@patch-diff-shortcuts <-- link to raw

That's not bad. Perhaps the blame link can be formatted like GitHub's comment links, live example:

#473 (comment)

Which for blame would be

.editorconfig@patch-diff-shortcuts (blame)

Edit: ⬇️ rebase only

Some thoughts:

Putting blame in brackets definitely seems nicer. I also noticed that GitHub puts the repo before the @ as seen in this comment: #467 (comment)
So maybe we should do that too:

• rollup/rollup/.eslintrc@master
• rollup/rollup/.eslintrc@rollup-init
• rollup/rollup/.eslintrc@rollup-init <-- link to raw

To differentiate between directories and repos, we could always add a leading slash before the path:

• /icon.ai@master
• /src/content.js@784a028
• /.editorconfig@patch-diff-shortcuts (blame)
• /readme.md@patch-diff-shortcuts <-- link to raw
• /src/content.js@master <-- link to raw

Don't forget tree links:

• /src@master
• /@diff-whitespace-bug
• sindresorhus/xo/lib@9fc3b06
• sindresorhus/xo/@9fc3b06 (not to be confused with https://github.com/sindresorhus/xo/commit/9fc3b0677eac477c94af67bc62257bb3d2273877 which GitHub transforms to xojs/xo@9fc3b06)

GitHub usually displays branch names with a blue background, via the branch-name class. Maybe you could do that too?

What about dropping the branch name if it's master?

• /icon.ai
• rollup/rollup/.eslintrc
• /src/content.js <-- link to raw
• /.editorconfig (blame)

Just now I'm doing a roundup of any links I find (top comment) so that they can be easily discussed and tested.

GitHub always displays branch names with a blue background, via the branch-name class. Maybe you could do that too?

That'd be nice, but there's no way to tell a branch apart from a tagname or commit:

https://github.com/nodejs/node/blob/master/.gitignore
https://github.com/nodejs/node/blob/v0.12/.gitignore
https://github.com/nodejs/node/blob/cc8fc46/.gitignore

Should they all (master, v0.12, cc8fc46) be blue?

What about dropping the branch name if it's master?

That was the initial idea, but if felt like additional context and there's always who uses branches other than master as the base branch.

The links to raw could use the regular parens syntax as well: rollup/rollup/.eslintrc (raw)

@sindresorhus @hkdobrev @jgierer12 please review the top post and let me know if any URLs should be added.

Missing repo pages: issues, pulls, milestones, labels, pulse, graphs

Should they all (master, v0.12, cc8fc46) be blue?

No, I'd prefer the normal, gray tag. I don't really mind if branches aren't blue, it was just something I noticed.

That was the initial idea, but if felt like additional context and there's always who uses branches other than master as the base branch.

Right, it will just get confusing if the default branch isn't master

The links to raw could use the regular parens syntax as well: rollup/rollup/.eslintrc (raw)

👍

pulse, graphs

There are actually a lot more of these but they're all the same, as far as we're concerned, no changes will likely be made other than to user/repo/pulse

How does this look? Try it on the first post in this PR.

Notes:

• All files are marked by @reference, this reduces ambiguity between
  • user/repo/file
  • user/repo/a-page-like-issues
• I kept the repo on the left side of @ to be consistent across all links:
  • user/repo@branch
  • user/repo/file@branch

Next:

• (How) do we shorten milestones further?
  Currently nodejs/node/milestone/25
• (How) do we shorten releases further?
  Currently nodejs/node/releases/tag/v0.12.0
  This can't be shortened to nodejs/node@v0.12.0 because it'd be the same as a repo link to a tag.
• (How) do we shorten labels further?
  Currently nodejs/node/labels/npm
  It'd be nice to match the color, but that'd require a fetch

Looking great so far!

Like I said, I would add a leading slash to directories/files to distinguish them from repos. e.g.
/some/dir@master vs some/repo@master

I would also print all of the repo pages with the parens syntax, e.g. user/repo (wiki), user/repo (projects)

For commits links, I think it would be better to use the singular (commit): nodejs/node/.gitignore@master (commit)

How about

• nodejs/node/25 (milestone)
• nodejs/node/v0.12.0 (release)
• nodejs/node/npm (label)

For commits links, I think it would be better to use the singular (commit): nodejs/node/.gitignore@master (commit)

That would make it look like it's a link to a single commit, rather than the list of commits coming up to it. Perhaps nodejs/node/.gitignore@master (history) would be an alternative.

For everything else: excellent, will do!

That would make it look like it's a link to a single commit, rather than the list of commits coming up to it

My bad, I actually thought they were single commits. In that case, commits sounds fine

Oooooook I think we're there.

Code-wise not 100% happy but I'm already at my third refactoring at this point. 😅

@jgierer12 I didn't shorten the milestone because the 25 (milestone) wasn't shorter than milestone/25; 25 isn't exactly indicative of its content; 25 looks too much like an issue number.

@sindresorhus I ended up going for cc8fc46.diff because my suggested cc8fc46 (diff)
may look like a link to the diff view rather than a diff file.

Can you add it to the feature highlights in the readme with a link to a screenshot?

Perfect

🎉

🍾✨🎉

🙌 Great work @bfred-it!

I'm loving this. Perhaps we should follow @hkdobrev's advice and use : between the repo and filename:

user/repo:filename@master <-- changes to :
/filename@master <-- stays the same

@bfred-it 👍

is there a way we can avoid some of these short bits on readme.md?
it's breaking my documentation commands, preventing easy copy paste

for instance:
git submodule add https://github.com/xxx/Docker.git Dockerfile
loses the URL so you can execute that

That should not happen (#789). URL shortening is supposed to only happen to real links. If it's a regression, open a new issue.