On the radar: git replay and jj

The git community is considering a "replay" command as a variant of rebase:

https://lwn.net/ml/git/20230907092521.733746-1-christian.couder@gmail.com/

As I was reading through the description, I saw that one of the motivations for this work is "jj is slaughtering us on rebase speed".  Not being familiar with jj or its murderous speed, I dug and found:

https://github.com/martinvonz/jj

Google, it seems, has put a full-time developer on creating an alternative to git. 

 On the radar: maintainers summit discussion about keeping old, unmaintained filesystems in the kernel:

https://lwn.net/ml/ksummit-discuss/ZO9NK0FchtYjOuIH@infradead.org/

The kernel has a "no regressions" rule, and it's hard to argue that removing a filesystem that has users is not a regression.  But there are also limits to how long some of those filesystems can be carried forward.

I looked at one aspect of this back in July (https://lwn.net/Articles/939097/), but the discussion seems destined to continue for a while yet.

Still, should this topic show up at the actual maintainers summit, I'm guessing Linus would stop it short by saying "we don't remove code that people are using; next topic". 

 On the radar: the 6.6 bcachefs discussion:

https://lwn.net/ml/linux-kernel/20230903032555.np6lu5mouv5tw4ff@moria.home.lan/

It turns out that if you ask to merge a big new subsystem that hasn't even been seen in linux-next, Linus gets grumpy with you.