Do you have a screenshot you can share? I only have "secret" stuff that I can't share.

If the tooltip is over a certain length, it could instead start to pretty print it and format it over multiple lines, with indentation and line breaks (like real code getting formatted).

That would be so good for readability! Am I missing a setting somewhere that does this?

Not sure about the annotation, but Javadoc apparently can’t be there, it has to be in a @param on the record itself.

I had to implement this at work.. Thanks JavaScript/JSON/Java/UTF-16 :/

What I like about fooToBar is that it lines up with the types and e.g. put(foo, bar) (and in general how a map is a foo -> bar).

What I like about bar(s)ByFoo is that it puts the more important thing first. And sometimes the "ByFoo" doesn't need to be explicit if it's clear enough without it.

Was the first time using the new Maven Central Publisher Portal, which is the replacement for OSSRH. Followed this guide: central.sonatype.org/publish/publ...

... and it worked on the first try! Seems better than the old system, kudos to the team!

@gork.bluesky.bot is this true?

One of my favorite little tricks to copy some git changes to another checkout is `git diff | pbcopy` in the source followed by `pbpaste | git apply` in the destination.

It doesn’t prevent anyone from handing in a blank vote (i.e. an “informal vote”). But yeah, compared to Switzerland, Australia has much less frequent voting, so maybe that helps.

I like that Australia has mandatory voting -> ~90% turnout: www.aec.gov.au/Elections/fe...

It was a great tool the few times I’ve used it, thanks!

Recently I’ve discovered @duckdb.org for this. While not a direct replacement, it allows processing CSV using SQL, e.g. see

Would be great to have it formalized, yeah! Excited for jj and other tools :)

I see, so it’s more like “it happens to work” than being explicitly supported at this point.

Oh, I didn’t know git allowed custom headers in commit objects, when did that happen?

Like:
- Conflicts can be resolved later, nice markers (with diff)
- Stable change IDs (and surprisingly short, no need to copy paste)
- jj new (with e.g. --after). Very convenient to work on stacked things in general
- rebase without having to check out
- push doesn’t need force
- log nice and short

I’m using it in one out of three of my checkouts (of the same repo).

Most of the initial issues I had have been solved (e.g. pushing and pulling works). Some that remain:
- LFS files need a workaround (just initially, not actively working with them)
- No indication of branch/status in IntelliJ