Mon Apr 12, 2021 1:12 am
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.
Mon Apr 12, 2021 2:57 am
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.
Mon Apr 12, 2021 3:26 am
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.
Mon Apr 12, 2021 4:47 am
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
Mon Apr 12, 2021 4:50 am
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.
Last edited by Graf Zahl on Mon Apr 12, 2021 4:55 am, edited 1 time in total.
Mon Apr 12, 2021 4:51 am
Yes, that is way too late. That's been since about half a year now and would require too many commits to undo.
Mon Apr 12, 2021 6:08 am
Graf Zahl wrote: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.
Mon Apr 12, 2021 6:19 am
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).
Mon Apr 12, 2021 6:21 am
No, that'd be the same as force pushing as it'd change the hash of this and all follow-up commits.
Mon Apr 12, 2021 9:46 am
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.
Mon Apr 12, 2021 9:54 am
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.
Tue Apr 13, 2021 2:51 pm
You can suggest feedback here
on GitHub if no one has done it yet.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.