lordmauve

I recommend wrapping the git cli commands using subprocess, using porcelain output modes etc, and parsing the output.

We have had stability problems with GitPython (which wraps gitdb). On Linux gitdb does clever things with sliding mmap, which caused some crashes (in a multi threaded environment), and I found simple race conditions in the code for writing loose objects, which is about as simple an operation as can be, so I lost faith with it. I do use gitdb in one read-only single-threaded system; it's undoubtedly fast.

The biggest issues with git libraries are around the complexity of git configurations. Any independent reimplementation is probably going to support the most common 99% of features but that 1% always comes back to bite you! We use a lot of git features in service of a gigantic monorepo, like alternates and partial clones and config tricks.

If we use command-line git we get 100% compatibility with all git configuration and ODB features, and it's hard to ensure that with an independent git implementation (even libgit2).

When you say "that solution doesn't scale well" - we have made it scale. git itself scales well for operations it can perform natively, you just have to use the features effectively, often the high-level operations but sometimes lower-level commands like git cat-file --batch, git mktree --batch, etc. It's not as fast as gitdb but fast enough, and I can have high confidence that I can write something once and it won't break or cause problems later.

I don't deny that this kind of thing is useful for understanding the capabilities and limitations of LLMs but I don't agree that "the best match of a next phrase given his question, and not because it can actually consider the situation." is an accurate description of an LLM's capabilities.

While they are dumb and unworldly they can consider the situation: they evaluate a learned model of concepts in the world to decide if the first word of the correct answer is more likely to be yes or no. They can solve unseen problems that require this kind of cognition.

But they are only book-learned and so they are kind of stupid about common sense things like frying pans and ovens.

I have always been very confused about whether the tip line on the receipt in the US works with my British cards given that I enter a PIN into a terminal that doesn't show that tip amount.

As of last year I'm pretty sure the tip is deducted from my card, but I don't think that has always been the case. I understand it works based on PIN-authenticated pre-authorisation for a higher amount and they later take your tip+bill from that pre-authorisation.

It doesn't seem very secure but the US always seems behind on card security.

When I first started travelling to the US for work restaurant staff were always extremely confused about why my card needed a PIN. They often tried again and again or said my card wouldn't go through, then worked out that it needed a PIN. Lots of places then had no way to hand you the terminal to enter it, like they would have to push aside mountains of junk to get the terminal out, or invite me round to the other side of the bar because it's literally screwed down.

Rust has a lot going for it beyond just the safety thing: excellent package manager, powerful trait system and generics, helpful compiler errors.

The whole language is designed to help you avoid making the programming mistakes people tend to make, not just the borrow checker and memory safety.

I don't understand the motivation to spoil your vote. First past the post is the shittiest voting system but the rational response is to vote tactically instead, perhaps reduce the majority of your disliked incumbent. Even if you can't overturn a majority, MPs on smaller majorities may be less arrogant, and less likely to vote for unpopular policies. But sometimes you do overturn a majority. It will happen lots in this/next year's election.

I don't think any politician gives a shit about the numbers of spoiled ballots, they literally don't look even once at those numbers.

Yes, Windows perfectly serves the purpose of running an SSH client to log into a Linux box. Totally adequate experience.

This software is not for you. It's for the author. It's in furtherance of their research, or their career, or their interests. It is only incidentally available to you.

That's it, that's the whole story. You get a GUI if the authors wanted there to be a GUI.

If you join a community around the product - which would require being nice, willing to engage, understand, not make demands - you might be able to give feedback and occasionally help steer the direction of the product.

And fuck you.

You mean...

This bullshit is why I use Pyrhon

Finally, the drivers will be able to play Angry Birds while they race.

Yeah, I shell out for the premium electricity, the 99% electrons. The 95% stuff is fine but I have a lot of expensive devices; I want them to run as fast as possible.