Github @mentions in commit messages

[Rachael]

For the time being, until Github gets its act together and takes this issue seriously - please do not put @names in commit messages.

I did not know Github handled this so poorly so I've done it before - and it's happened to a couple other people now - you cannot turn off the messages and then the @mentioned will get an email literally every time someone creates or updates a fork or uploads a repo with GZDoom's history in it.

As you can imagine, this can get very annoying ... very quickly... especially when your intent is to give credit/attribution/acknowledgement, not to annoy the person.

[dpJudas]

Oh yes please. I've gotten over 20 emails so far thanks to such a mention upstream. I'm seriously starting to consider disabling notifications as a result of this.

[Graf Zahl]

Let's extend this a bit: PR's with such mentions are to be closed on sight with a request to resubmit. I will also remove any such commits that already got in via force push in the future if I notice too late.
Github's notification system is a major annoyance for sure with totally inadequate filtering options. I normally use a special email dump account for such noisy services. The garbage that accumulates there is incredible. But with Github I cannot do that.

[Nash]

Agreed with the commit message curation.

While we're on the topic, Graf, would it be too late to force push one such offending PR made by me?

[Graf Zahl]

I'm afraid that one's too old, it'd require rewriting half a year of commit history. If it meant redoing, say, 10 commits it'd be fine but half a year is too much.
Remember - this would affect all project forks, so force-pushing is only an option if forks can easily adjust to the change.

That one @mention for dpJudas can probably still be removed but the next oldest one is already from Jan 5th.

[Rachael]

Yes, that is way too late. That's been since about half a year now and would require too many commits to undo.

[Rachael]

That one @mention for dpJudas can probably still be removed but the next oldest one is already from Jan 5th.

Yeah in a "technical sense", there are no merge commits since that happened. Those are what actually get in the way.

However though - it might even still be too late, because he would appear in downstream pulls, and there are a lot of copies of those by now. Rewriting history is extremely complicated for those - and more often than not causes more problems than it solves.

So while technically the issue can be solved on our side - in a practical sense, it pollutes both existing local and copy/fork repos, and often in a really nasty way for the unfortunate owners of said repos.

[Nash]

Would hard editing the commit message files solve anything? I have seen some tutorials about editing commit messages that involve digging through the Git-managed files but I've never actually tried it, but more importantly I wouldn't know if Github's infrastructure is coded well enough to "see" the change or not (my guess would be the latter, haha).

[Graf Zahl]

No, that'd be the same as force pushing as it'd change the hash of this and all follow-up commits.

[NY00123]

On a related note, it may also be worthwhile to refrain from mentions of issue numbers in commit messages, as in "fixes #4".

While it's a convenient method of auto-closing open issues, the problem is that this can also propagate to separate forked repositories, in which unrelated issues can be mistakenly auto-closed as a consequence.

The same might apply to merge commits with texts like "Merge pull request #1000".

While the priority for this might be lower, there's also a question of semantics. If the repository is ever migrated to a different platform, the issue numbers won't have a meaning on their own, unless their source is explicitly specified.

Even a short description of the repository (e.g., a combination of account and repository names) may already be better.

[Rachael]

In that case, you can still paste the URL of the issue and it will be handled as normal, but will mitigate the side effects you mentioned.

For example, instead of saying "fixes #4" put in the commit message "fixes https://github.com/yourname/gzdoom/issues/4" - same effect, but doesn't auto-close issue #4 in child forks.

[Major Cooke]

You can suggest feedback here on GitHub if no one has done it yet.