These has two problems, first it will impose you to use the official or a compatible GitHub interface, not the command line or whatever git GUI interface you want. Even with that, it is impossible to use offline, while your git history is local and can be consulted whenever you want without a connection, and you can make whatever changes you want and push them when you have internet access.

The second problem is that it's not portable, it's something internal of GitHub, that is fine till you use GitHub, when you need to migrate to another server, or host your own git repository, for reasons (GitHub changes plans, GitHub closes down, GitHub no longer wants to host your project, etc) what do you do?

These issue numbers are non-portable even within github! Two repositories may have the same commits in them but different sets of issues.

My favourite is when someone collaborates on a PR and they create PRs for the PR's branch in the forked repo. That repo has its own numbers so you'll end up with merge commits referencing PR #4 in the main repo.

this came very close to exposing private repo details to the wrong users for me recently

currently trying to find an exploit using this 'feature'

Because forks are GUI sugar for refs in the main repo.

This is also why Actions have convoluted security implications.

No I didn't mean the "you can replace the fork's URL with the main repo one and make the commit seem part of the repo". That's a weird github oddity to keep in mind, but not the issue I meant. I meant when that PR including its merge commits gets merged. Then those commmits become proper members of the main repo.

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.

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/8b4b1831e333a43d...

> 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/CommitMessageConventio...

The "git interpret-trailers" command exists to work with this kind of data.

Having a number short-form is a de-facto standard across most "version control+issue tracker" services.

For nearly all cases it's good enough, projects like the Linux kernel are in the end an exception wrt. their requirements and workflow. Most project are just hosted in one place so the shorthand is always clear, and has the benefit of not being "broken" if a project is renamed/moved.

Furthermore GitHub always allows the user to specify the commit message, it just prefills some hint. But it can't really know your style of using git so it can't do much more then just prefilling the hints. But you can always write them the way you want to filling in all the details needed.

Through IMHO the problem are non-ff git merges in general, not only do they motivate bad commit messages but also does "not having merge conflicts" in no way mean there is no problem. I had more then one time where a "no conflict" git merge introduced bugs.

Projects like Linux are a bit special due to the size, number of contributers and sizes of contribution.

But for most projects I can just strongly recommend to only allow FF merges and locally rebase branches on master if it doesn't work. Preferable with users using interactive rebases to create nice commit histories, alternatively squashing works to but git is just _bad_ at squashing and so are tools based ontop of it (e.g. GitHub).

If the data is not stored in the git repo itself there is no workable solution. Any offered standard is just a bandaid on the problem.

If a project is renamed or relocated from one name to another it might (and should) preserve issue and merge related information and discussion, but any full URLs will have changed, making full URLs fail in specific cases. Using any form of shortened sequential identifiers will fail when referenced in commits merged in from forks of the project that have their own conflicting identifiers.

To solve this in any real way there needs to be a way that when a project is forked it carries information about issues and merges with it, and when commits from that fork are merged back into the main project, or merges from a fork of a fork are merged all the way back to the original project, all metadata about those merges are carried to the original project.

Linus' argument is that the correct place to store that is in the merge commit's message. That it is the responsibility of the person doing the merge to provide that information, and that GitHub does a bad job of providing tools to do that.

Note that if you like to keep reference to merge requests and the "commit grouping" that merge commits allow, you may very well use FF-only merges with merge commits. You can then use things like `git log --first-parent` to have sort of high-level "merged MRs" view on your history, which may be useful for some workflows. GitHub's (and GitLab's) history view is pretty bad, but that doesn't mean all history views are so featureless as these Web UIs ;)