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).