u/Alphare

100%, 6C+ is for grumpy sandbaggers (which is why I downgrade 7As to 6C+, the only way of doing them) 

A whole 12m. I've been to see it, it would have been a highball in the US

Well Mercurial has a large core part already written in Rust, so at this time it's just a matter of me deciding that the crate looks good enough/trustworthy enough. I may look into it in December when I have a large repo available to try out

Thanks for sharing! I went to the GitMerge conference last week and people were discussing hashing speed. It is also a concern in Mercurial land and we've already tried a bunch of stuff to work around how slow SHA1DC is, but this looks promising to reduce the overhead further :)

Rare Mercurial win ;)

Always interesting to learn how projects work around the lack of proper tooling in version control systems for monorepos. I have good hope that in not that long we'll have a truly seamless experience for sub-projects in monorepos. But in the mean time this looks like a good tool.

Socks wearer here but I haven't climbed harder than V6/7 outside so maybe that's the problem

Because this is a pet peeve of mine, I looked very quickly at the code and you should be aware that not everything is UTF8, meaning that most of the places where you use String should be using another type. :)

Thanks for doing version-control related tooling!

Oh this thread reminds me that I have 80% of an email typed up with a repro of how comically btrfs doesn't scale with threads in at least my particular scenario. I should get to sending this email to their list soon because we use btrfs for a lot of things.

Great work! I spent a lot of time making Mercurial's status super fast on Linux a while back. From what I know, no implementation of Git comes close with the pure Rust client, but it's been a while since I've measured. It take ~40ms to do a status for 600k files in the Mozilla source on my machine where any Git implementation took more like 200ms even with untracked cache. However I've never had the time (funding or motivation) to look into Windows performance, and this gives me more hope than I had from a distance. I'm on vacation on my phone so I can't really dig deeper, but I love a snappy VCS so thanks for showing we can do better! 

Good job gumby, I remember my v17 plateau (v20 in your crag) 

One day I'll actually get around to separating the .hgignore logic from our core crate and making it available so it's usable in ripgrep... Thanks for the work as always, it's a fantastic tool.

/uj reminder that such neck adjustements can lead to a stroke or even death via coronary artery dissection and you just never ever let anyone do this to you

(Sorry)

Thank you! We're trying our best 

As one of the maintainers, I would say yes. :)

As the person that contributed precompiled headers caching to sccache, I'm curious what problems you've encountered with this feature specifically. Or was it that simply the feature wasn't there when you last used sccache?

Excellent article. The only weird thing is their opinion that Rust answering 17 for the length of the string containing the single emoji is wrong. The API is defined as the number of bytes in the string, and Rust explicitly does not want to have unicode aware code exposed in the stdlib because it changes all the time, as the article mentioned. So I'm not sure why it's not mentioned as a practical and more cautious API instead of a mistake.

(hinting at the hash-object part) FYI, the reason why Git (and other VCS, wink wink) hash the contents pre-compression is to make sure that the content is exactly the same, bit for bit, using a cryptographic hash function. Not sure if this is something you knew but didn't mention, but I feel like this is a pretty important decision to understand when talking about VCS internals. :) Great video as always!

Thanks a lot for this! I've been having drops in LDAC, SBC seems to work better. I wouldn't have thought to look in the dev tools.

If you look closely you can see aid with the rope grab near the end. Impressive dyno nonetheless