←back to thread

94 points vincent_s | 6 comments | | HN request time: 0.83s | source | bottom
1. snthpy ◴[] No.40913276[source]
I saw a youtube talk on this a year or two ago and it looked promising. I've been waiting to see more people take it up and sing its praises. This is the first HN post I've noticed since then.

Any experiences of anyone trying it out and switching over to it?

replies(4): >>40913324 #>>40915893 #>>40915927 #>>40930186 #
2. snthpy ◴[] No.40913324[source]
I think this was the talk: https://youtu.be/bx_LGilOuE4?si=K7k0hqUmeXl8ULLf

I would like to know more about the first class conflict handling. That could potentially be useful for an application I have in mind but I need to understand the algorithms better. How does it compare to CRDTs or other merge strategies?

replies(1): >>40917456 #
3. 3523582908 ◴[] No.40915893[source]
It's been my daily driver for the last 3 months, and it's really amazing. Highly recommend trying it out!
4. stouset ◴[] No.40915927[source]
I expected it to be a bigger migration than it was. But I was using it effectively as a complete git replacement the very first day.

I still had a few things I didn’t know how to do optimally, but it was close enough to be productive. Within a week I’d closed basically all of the gaps.

It’s been three or so months now and I’m never going back. It’s been so transformative I can barely remember all the innumerable frustrations and papercuts I used to put up with daily. Rebase conflicts. Juggling the stash. Ugh. I say this as someone who considered themselves extremely proficient with git. I mean, I wrote a compatible Ruby implementation of it over a decade and ago.

If it gains momentum, jj has a better chance than anything I’ve seen at finally dethroning git.

5. stouset ◴[] No.40917456[source]
The easiest way to think about it is that merge conflicts aren't something that causes operations to be aborted like they are in git. If you have a merge conflict or a rebase, conflict markers are inserted and everything continues.

You can quickly see any commits that have merge conflicts. If some operation introduced them, you can go edit that commit and fix them. When you do so, the fix propagates forward automagically to all descendant commits. The benefit here is that the operation you were trying to do fully completes and you're never ejected into an intermediate state where changes are dropped into your working copy and you're expected to fix it right here and now before anything else happens. You don't have to unwind everything because you screwed up an earlier conflict resolution since everything is stored in history; you just go back to the commit you want to fix, make a change, and then jump back to the later commit that still needed some work.

6. steveklabnik ◴[] No.40930186[source]
It took me like a week to get the hang of it. Haven't gone back to git since.