Use stricter regex for @mention match - Githubissues

fraction / oasis

Free, open-source, peer-to-peer social application that helps you follow friends and discover new ones on Secure Scuttlebutt (SSB).

http://oasis-demo.fraction.io

GNU Affero General Public License v3.0

286 stars 42 forks source link

Use stricter regex for @mention match #469

Closed christianbundy closed 3 years ago

christianbundy commented 3 years ago

What's the problem you solved?

Problem: You can't publish email addresses or user@host combos or anything like that because the regex is super liberal in what it matches.

What solution are you recommending?

Solution: Ensure that the first word in a message is a mention or ensure that there's whitespace before a mention. This also adds a regex101 link (in lieu of proper testing, for now) which makes this easier to test and track over time.

See-also: https://github.com/fraction/oasis/issues/466

christianbundy commented 3 years ago

cc: @cblgh

cblgh commented 3 years ago

cant access regex101 atm, but the additional strictness (start of line or space character) looks good!

black-puppydog commented 3 years ago

Yes, this looks useful! Even if it's not 100% and we'd still want to do other things, I'd want this.

christianbundy commented 3 years ago

THANKS! Please merge whenever @black-puppydog.

black-puppydog commented 3 years ago

waiting to do one more test right now :P

black-puppydog commented 3 years ago

one day the good people at github will allow us to select "semi-linear" merging aka "rebase and merge with merge commit". *sigh*

christianbundy commented 3 years ago

what's the problem with a regular git merge?

black-puppydog commented 3 years ago

https://github.com/isaacs/github/issues/1017 I think this one explains it well.

git history diagrams

black-puppydog commented 3 years ago

It's a bit of a soapbox of mine. I've been drilling engineers at work to pay attention to the commit logs, because they're so damn useful for regression debugging.

christianbundy commented 3 years ago

I've been drilling engineers at work to pay attention to the commit logs, because they're so damn useful for regression debugging.

I couldn't agree more! But this is usually why I hate rebase-centric workflows, because they mutate commits and obfuscate what the real tree was during a PR. For example, maybe this PR only works with the package-lock.json from yesterday, and one of the new PRs that were just merged actually broke this commit -- if we use any rebase we're likely to mutate the history so that it looks like this commit seems like the broken one (instead of showing that it was on a branch that was fine because it had another parent).

Would love to discuss this with you, because I also feel very strongly about dev workflows. Maybe we should find another place to discuss tho? :laughing: