3 ms·

I don't work for GitHub, but I would eat my shoes if GitHub made any conscious choice at all in their design regarding keeping people on the web UI. It sounds a

I don't work for GitHub, but I would eat my shoes if GitHub made any conscious choice at all in their design regarding keeping people on the web UI. It sounds almost exactly like a decision made to keep some sort of backwards compatibility without having to do any extra engineering, stray far from vanilla Git, or make the user experience worse for regular users.

est31 5y ago
The issue with full URLs is renames of user or project names. I don't trust the inbuilt redirection support of Github this much. Plus, tools that don't shorten full URLs would get extremely long lines in their commit messages. I think the Github issue numbers translate 1:1 to Gitlab if you use the Github->Gitlab exporter. If you used full URLs, it would either have to keep the URLs, or change commit hashes, neither a really nice option. Also, not that chromium did something different. They reference tons of internal bug IDs, change IDs, and this commit msg also has an URL with the non-standard domain go (no TLD): https://github.com/chromium/chromium/commit/8b4b1831e333a43d2da2d642d1b05256b1a921ed https://github.com/chromium/chromium/commit/8b4b1831e333a43d...
- anonydsfsfs 5y ago
  > Also, not that chromium did something different. They reference tons of internal bug IDs, change IDs, and this commit msg also has an URL with the non-standard domain go (no TLD): The kernel does that too. Those key-value pairs are called "trailers", and are semi-standardized at https://git.wiki.kernel.org/index.php/CommitMessageConventions https://git.wiki.kernel.org/index.php/CommitMessageConventio... The "git interpret-trailers" command exists to work with this kind of data.