3 ms·

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backen

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.

steveklabnik 1y ago
I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.
- baq 1y ago
  I think git compat is the absolute #1 priority for working devs to even consider seriously checking version control tools out. I wouldn’t have tried jj if I couldn’t run it on my work git repo and I didn’t try pijul on my work repo for this reason. It hurts my inner geek who’d like to try using it for something professionally.
- coastalpuma 1y ago
  > The benefits touted are very abstract Not really? From someone's post here a year ago: > The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id. Anybody who's wrestled with reordering/rebasing git history or has done git archaology is able to understand this benefit. From Pijul's site: > Pijul is the first distributed version control system to be based on a sound mathematical theory of changes After years of grudgingly tolerating using a deployed prototype for a VCS, yes, I want the mathematically sound alternative. All that being said, I do wish you the best, because truly, I am tired of git and JJ does seems like an improvement.
  - Dylan16807 1y ago
    Do I benefit from getting the same hash no matter what order I put the patches? In fact getting the same tree either way feels like information loss. Even if I only merge, won't I lose track of what the actual state was when each commit was made? Most of my wrestling is with merge conflicts and a consistent tree doesn't help with that.

Agree, the feature of commutative patches just seems obviously superior? Not sure why there's a critical mass to adopt jj over Pijul apart from jj's git backend.

steveklabnik 1y ago

I think this gets at one of my original comments in this thread: I think the reason of commutative patches has communication issues. The benefits touted are very abstract. The problems I’m aware of it solving are mostly theoretical problems for working devs, and so the message hasn’t landed. If I were interested in advocating for these tools, I’d be trying to find a message that does resonate.

baq 1y ago
I think git compat is the absolute #1 priority for working devs to even consider seriously checking version control tools out. I wouldn’t have tried jj if I couldn’t run it on my work git repo and I didn’t try pijul on my work repo for this reason. It hurts my inner geek who’d like to try using it for something professionally.
coastalpuma 1y ago
> The benefits touted are very abstract Not really? From someone's post here a year ago: > The real innovation of a lot of these alternative DVCS systems is that they free the state of the source from being dependent on the history that got you there. Such that applying patches A & B in that order is the same as applying B' & A' -- it results in the same tree. Git, on the other hand, hashes the actual list of changes to the state identifier, which is why rebasing results in a different git hash id. Anybody who's wrestled with reordering/rebasing git history or has done git archaology is able to understand this benefit. From Pijul's site: > Pijul is the first distributed version control system to be based on a sound mathematical theory of changes After years of grudgingly tolerating using a deployed prototype for a VCS, yes, I want the mathematically sound alternative. All that being said, I do wish you the best, because truly, I am tired of git and JJ does seems like an improvement.
- Dylan16807 1y ago
  Do I benefit from getting the same hash no matter what order I put the patches? In fact getting the same tree either way feels like information loss. Even if I only merge, won't I lose track of what the actual state was when each commit was made? Most of my wrestling is with merge conflicts and a consistent tree doesn't help with that.