I have been using Claude for 95% of the mechanical coding for months, and jj has proven to be more relevant than not for me. Because it is a better VCS tool than git, it allows to work with the firehose of commits much more seamlessly.
From practical experience from using jj daily and having (disposable) mega merges:
When I have discrete, separate units of work, but some may not merge soon (or ever), being able to use mega merges is so amazing.
For example, I have some branch that has an experimental mock-data-pipeline thingy. I have yet to devote the time to convince my colleagues to merge it. But I use it.
Meanwhile, I could be working on two distinct things that can merge separately, but I would like to use Thing A while also testing Thing B, but ALSO have my experimental things merged in.
Simply run `jj new A B C`. Now I have it all.
Because jj's conflict resolution is fundamentally better, and rebases are painless, this workflow is natural and simple to use as a tool
> Because jj's conflict resolution is fundamentally better
I don't know jj well so its merge algorithm may well be better in some aspects but it currently can't merge changes to a file in one branch with that file being renamed in another branch. Git can do that.
I'm not immediately aware. There's a certain amount of git-ness embedded in it with it being a DAG, having commits, and being compatible with git remotes. And, since the industry still runs on git, most people will need to learn it somewhat, anyway.
Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.
And I hope you do. It is so much better than git in every way. It enables working with stacks and the aforementioned megamerges so easily, allowing me to continue working forward while smaller units of work are reviewed/merged.
When I first tried to use jj, I wasn't entirely committed and switched between jj and git. Finally I hit a breaking point being fed up with stacks/merges and tried jj _for real_.
I recommend to give it a serious try for a few solid days and use it exclusively to really understand it. You won't go back.
The jj Discord is a very helpful place. Thanks to everyone there. Great article Isaac!
I tried out with a tiny project. It is the muscle memory built up with Git that kicks in and wish that JJ does it. I went through all the raw mistakes and doing things the hard way with Git, that, my mind plays trick trying to use JJ with the Git mindset. For now, I have mapped all of my Git aliases to JJ equivalent. But I would like to learn it the right way and do it the JJ way. This is going to take time, I’ll go slow.
I really recommend just ripping off the band-aid and using jj "as intended". It took me only a day or two to adapt, and a week to feel like I am now a jj native. It's really a tiny cost to pay, and way less than the overhead of maintaining a bidirectional mental mapping between jj and git.
> Trying out jj is super low-risk--since it uses git as a backend, you can test it out and bail back to git without any drawbacks other than a detached head state.
Btw, the risk of trying out other modern version control systems is nearly as low: most of them are compatible with git and you can convert back and forth. That definitely includes mercurial etc.
I tried Sapling (Facebook's fork of mercurial with more polished git-compatibility layers) and never looked back for any of my own projects.
I recently started a new job where the vanilla git CLI is the only git frontend installed on company servers, and the regressions in user-experience are painful :(
> According to a Stack Overflow Developer Survey, almost 90% of developers use Git, while Mercurial is the least popular version control system with only about 3% developer adoption. In fact, Mercurial usage on Bitbucket is steadily declining, and the percentage of new Bitbucket users choosing Mercurial has fallen to less than 1%.
I’ve been loving it for personal projects. But for work, some of our homebrew tooling relies heavily on hashes. So any operation that causes snapshotting to occur tends to lead to breakage that utterly confounds Claude. I tried giving it rules and instructions to make sure to sync git up to the correct commit for the current snapshot, but as soon as the signal for that is too week in the context it blows a gasket trying to figure out what has gone wrong.
Well said. If Matthias, a person who programs Python scripts for stress testing machines, and can navigate the hideous UI/UX of some digital oscilloscope, is not "computure-savvy"...
Give any of us a tired morning without coffee and a mis-click, and many of us could be in the same predicament.
It's awful that only a privileged subset of hacked users may get enough public attention to have Google give special treatment.
But I hope Matthias gets his channel back. I'm a long-time subscriber to both of his channels. Hopefully my comment adds into the pile and brings more notice to him :)
I used to be so pleased with CenturyLink myself. symmetric 1Gbps as well, and it was dreamy.
Then I began to exhibit packet loss. For gaming/discord, it's a death knell. I isolated the source of packet loss to be within the CenturyLink network, basically between me and the first traceroute hop. (Also retroactively verified by switching ISPs)
CenturyLink as an _offering_ is great, but their company operations and customer support is... kafkaesque and absurd. They are beyond incompetent and seem to have neither the capacity nor desire to fix any real problems.
When talking with some of the technicians and support people, the insight into their world was sad and disappointing. What a ramshackle company.
I really hope nothing ever goes wrong in your network segment :)
You are right, CenturyLink support is apparently non-existent these days. My aunt recently had issues for weeks before finally giving up trying to get any real engineering support, and eventually it resolved itself, presuming some monkey noticed a rampant trend for problems in the area. Cox wasn't much better at times unless you knew exactly how to deal with support (I for a time ran part of their engineering and do), but it's still volumes better than the worse than nothing you get with CenturyLink now.
That said I've been lucky, in the 6-7 years I've been on CL moving from Cox I've had 0 problems with my DSL, where I'll say there's something to be said for the old legacy 2-wire stuff. At least every 3-4 years, I'd have to have cox out to fix my cable terminations for suck-out (center conductor eventually contracts itself to lose contact with hot/cold over time) with the extreme heat in Phoenix, so it's been almost a nice change.
