Yes, things that are not LLMs continue to be useful and interesting even though LLMs exist.

I hate what AI hype is doing to peoples' brains here.

I was a loyal magit user for a decade. Now I use jujutsu from the command line. It's actually really nice.

Git is noticeably slow on Windows. Git is built to run on top of Unix commands, which work great on Linux and Mac. For Windows, the commands have to be installed separately, and there's a performance penalty for each call. Individual Git commands are usually fine, but anything that calls several steps in sequence will visibly drag.

(WSL gets around this entirely.)

afaik far bigger factor is that windows file io is just generally much slower than linux. both of these are further exacerbated by av solutions which are ubiquitous in windows. that is why ms introduced "dev drive" in windows few years back which in their own benchmarks showed biggest gain specifically with git: https://blogs.windows.com/windowsdeveloper/2023/06/01/dev-dr...

I hardly see developers with Windows anymore, I guess this is one of the many reasons.

I have to use Windows for work. With WSL, it's actually perfectly fine! Which is really more of an endorsement of Linux than Windows.

I last developed on Windows in the time where I had to fiddle with Git Bash, Cygwin and manually setting my PATH. It was not a fun time.

I've had two Pocketbooks and never encountered these issues. Sounds like you had some bad luck.

Kobo works with Libby if you use Adobe Digital Editions as an intermediary.

From the Libby web page, you have an option to download the ASCM. Load that onto ADE, and you have the book. Then plug in your Kobo and transfer the book. It even respects the loan duration!

This isn't perfect, but it works, so I can't agree that Libby and Kobo are absolutely incompatible.

I tried that, and it was incredibly frustrating to have to run back to the PC every time, not to mention vacations and things like that. At that point you don't even need Libby since you can do the same with digital editions off your library's website.

I truly hope you're buying books as well - authors (and editors, illustrators, translators, etc) should be rewarded for their art.

One of my favourite writers only publishes on Amazon, so I subscribe to their Patreon to offset the fact I "acquire" their books with alternate means.

Yes, it's not hard to do both.

The Kindle scene is a disaster that shows the dangers of prioritizing DRM. Meanwhile, I'm buying DRM-free books and keeping them in Calibre and reading on KOReader. It's a great experience.

Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.

Hmm, that feels a bit subjective - I'm not going to say X is easier than Y when I've just finished saying that I found both tools to have a lot of black magic happening.

But what I will point out, for better or worse, people are now looking at LLMs as Git masters, which is effectively making the LLM the UI which is going to have the effect of removing any assumed advantage of whichever is the "superior" UX

I do wish to make absolutely clear that I personally am not yet ready to completely delegate VCS work to LLMs - as I have pointed out I have what I like to think of as an advanced understanding of the tools, which affords me the luxury of not having an LLM shoot me in the foot, that is soley reserved as my own doing :)

Cherry picking is just convenience for something that anyone could do manually. If it didn't exist in the VCS, people would do it anyway and make tools to do it.

Fossil's implementation is the best, since a cherry-picked commit always points back to its origin.

Speaking as a former Darcs user (Darcs is another patch-based VCS that Pijul draws inspiration from):

"This is a useless property because the graph is only encoded at the patch layer. In the real world you have far more semantic dependencies than patch dependencies. ie, I have a patch that adds a function that calls a function added in another patch. Pijul doesn't know about that."

Darcs solved this in two different ways.

1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.

2. Practicality. In reality, there's no scenario where someone is pulling your "use function X" patches and also not pulling the "define function X" patch. They could if they really want to, but this would be a lot of effort for a deliberately bad result. It would be like, in Git, cherry-picking the "use" patches without the "define" patches. In neither system would this happen by accident.

"Conflicts coming back is not an issue in git. For some reason people think they need to use rebase when they should almost always be using merge."

There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.

I deliberately moved away from Darcs after a few years - the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened. (Also branch discovery in Darcs basically doesn't exist; Pijul fixed this, at least!) I love Fossil and Mercurial for their adherence to accurate history.

What I want is a system that records how conflicts are resolved and tries to apply that resolve. Lets say I have apply patch A, then patch B, there is a conflict, I resolve it. Then someone else applies patch B and then patch A. The VCS should know that this conflict is already resolve and apply the solution. Likewise when applying first patch C, then A and B, it should let you resolve the conflict from AB to ABC and again record the resolved conflict for the future. I'm actually fine with manually resolving conflicts, but don't want to it twice if I don't have to. This would be a great way to organize something like dwm, but I couldn't get it to work with pijul at all.

I believe this is what `git rerere` does

> 1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.

I don't know who would want to put in the work of mapping out the semantic dependency graph because maybe some day someone might want to compose a slightly different set of patches. And even if everyone tried, it would surely still fail because that's so hard or impossible.

> There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.

Just stop using rebase is much easier to socialize than let's all move to Pijul. It's also the correct thing to do.

> the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened.

I strongly agree with this and think it's the only tractable way to operate.