Hacker News new | ask | show | jobs
by steveklabnik 244 days 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.
2 comments
baq 244 days 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.
link
coastalpuma 243 days 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.

link
Dylan16807 243 days 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.

link