I think that the ability to collocate with fit is really the thing that makes even evaluating the use of jj feasible in many organizations. To consider pijul, it requires throwing away all of your forge setup, configuration, permissions, backup, disaster recovery, as well as updating every CI pipeline.
In a very real way, git won, and the inertia behind git is higher than it was for any VCS tool before it, and so just being better isn’t going to be enough, you’ll also need to interoperat.
I strongly suspect that its not feasible to colocate pijul and git. git and jj are based on snapshots, while pijul is based on patches. They have very different models.
As long as some repository state in either system can map onto a checkout in the other system it should be possible at least in some capacity. I’d like to try out pijul at work, but I’d need an analog of jj git fetch and jj git push. Whatever happens in between doesn’t really matter too much unless it’s tedious manual bookkeeping to maintain history mapping.
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.
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.
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.
> 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.
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.
