maddie

oh hey, that's my article!! thanks for sharing it

s/clear case// 🙃

i've also had to subscribe to several blocklists in an attempt to stem the tide of facebook-style american liberal political memes

ironic that this post was brought to me by discover, but i completely agree

> as long as you don't log them

to help with this part, you can use something like secrecy::SecretString docs.rs/secrecy/late...

This will display only emails, unless the email is one of those GitHub ones, in which case it will display only the author's full name, followed by "(GitHub)".

[template-aliases]
'format_short_signature(signature)' = '''
if(signature.email().domain().ends_with("users.noreply.github.com"),
signature.name() ++ ' (GitHub)',
signature.email(),
)
'''

A screenshot of text in a terminal window, displaying a graph of revisions as output by the jujutsu version control system. Some of the revisions in the list display their author as "Sam (GitHub)" or "dependabot[bot] (GitHub)", while others simply display email addresses.

Related tip: I've come to quite like the way #jj-vcs displays only committers' email addresses (not full names) in the log by default, but what I don't like are the autogenerated `@users.noreply.github.com` emails that are attached to commits that were merged directly on github.com. So, a solution:

(Oops, I had to delete and repost this because I made a typo in the config snippet the first time 🫢)

*I'm* excited about this even though it's been supported since 0.23.0, just because it was only yesterday that I was able to update past 0.20.0 due to reliance on unmerged mailmap support - but maybe this has become common knowledge since then!

[template-aliases]
'format_timestamp(timestamp)' = '''
if(timestamp.before("1 week ago"),
timestamp.ago() ++ timestamp.format(" (%Y-%m-%d at %H:%M)"),
timestamp.ago()
)
'''

A screenshot of text in a terminal window, displaying a graph of revisions as output by the jujutsu version control system. Timestamps in the list from within the last week are displayed using relative phrasing ("3 hours ago", "17 hours ago", and so on) but timestamps from longer ago also display an absolute timestamp, such as "1 month ago (2025-03-06 at 13:03)".

#jj-vcs tip of the day: if you like the idea of relative timestamps for revisions but are reluctant to commit because you feel they're not really useful past about "1 week ago" - well first of all, you and I have something in common! But secondly, jj supports this; try setting this in your config: 🧵

i knew you were cool!

Mine's not that crazy, it's just some vim bindings that copy the GitHub permalink to the current line (or range of lines). I use it constantly, it's been way more useful than I expected!

And once again, intersex people have been completely ignored

oh, actually, i think i'm wrong - i checked, but misread the IPA

the one that rhymes with "myopic" is the "correct" pronunciation - as far as i know, the "bio-pic" one is a recent trend

i've had this problem too, it's like "wait, what do you mean i have to create a branch first?"

and implementing FromStr for T "automagically" gives you the ability to call str::parse::<T>()!

at the same time as i'm trying to speak with some level of authority about unsafe code here, i *also* try to avoid writing any as much as possible :)

you make a good, interesting point! my statement about unsafe rust still being safer was w.r.t. the fact that your code's usage of anything other than raw ptrs is still governed by the same rules as safe code. maybe it comes down to how you measure the relative impact of that vs your ptr... point?

if you're interested in digging a little deeper, take a look at this section of the Rust book! it discusses this, and points out among other things that you still have the borrow checker active even in unsafe code: doc.rust-lang.org/book/ch19-01...

even unsafe Rust is considerably safer than C. there are applications that require the use of unsafe, like interoperating with C code - but the advantage of using Rust even though some of it might be unsafe is that the *rest* of your code will be in safe Rust!