Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pijul a FOSS distributed version control system

pijul.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Pijul a FOSS distributed version control system

#21

Post by EnPissant »

WolfeReader wrote: post #16
EnPissant wrote: post #7

From their home page: > Why? > Commutation > In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pi…

Speaking as a former Darcs user (Darcs is another patch-based VCS that Pijul draws inspiration from): "This is a useless property because the graph is only encoded at the patch layer. In the real world you have far more semantic dependencies than patch dependencies. ie, I have a patch that adds a function that calls a function added in another patch. Pijul doesn't know about that." Darcs solved this in two different…

> 1. Dependencies. While Darcs patches would inherently "depend" on the last patch which affected the same lines, the committer could specify other patches as dependencies, handling exactly the case you described.

I don't know who would want to put in the work of mapping out the semantic dependency graph because maybe some day someone might want to compose a slightly different set of patches. And even if everyone tried, it would surely still fail because that's so hard or impossible.

> There's a big difference between "conflicts shouldn't come back as long as everyone does what I want" and "conflicts don't come back". As long as you're using Git with other people, the rebase-lovers and their problems will be a perpetual issue. I've been on 3 teams in a row with this problem.

Just stop using rebase is much easier to socialize than let's all move to Pijul. It's also the correct thing to do.

> the benefit of snapshot VCS is that you don't just have the change, but you have the whole context in which the change happened.

I strongly agree with this and think it's the only tractable way to operate.

Re: Pijul a FOSS distributed version control system

#22

Post by EnPissant »

riffraff wrote: post #19
EnPissant wrote: post #12

Earlier quoted context omitted.

I think patching/cherry-picking is just inherently complicated and needs intelligence applied. I don't think Pijul is going to be any better here.

I remember working with darcs 20 years ago (pijul should be on that lineage) and cherry picking in that was way better than doing it with git since it meant "get this change and all the required ones" rather than "pick this commit". It still required intelligence (changes across files may not be tracked as dependent but actually are) but it was a different experience from what git provides.

If you really wanted, you could implement this on top of a snapshot based system by mixing in git blame information (or an algorithm that is similar). It's not hard to compute that text based dependency graph on the fly, though maybe expensive without caching.

Re: Pijul a FOSS distributed version control system

#23

Post by EnPissant »

emmelaich wrote: post #15
EnPissant wrote: post #7

From their home page: > Why? > Commutation > In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pi…

> Git can checkout only a set of files or directories How do you do this? With submodules / subtrees?

git sparse-checkout

Re: Pijul a FOSS distributed version control system

#24

Post by [deleted] »

emmelaich wrote: post #15
EnPissant wrote: post #7

From their home page: > Why? > Commutation > In Pijul, independent changes can be applied in any order without changing the result or the version's identifier. This makes Pijul significantly simpler than workflows using git rebase or hg transplant. Pijul has a branch-like feature called "channels", but these are not as important as in other systems. For example, so-called feature branches are often just changes in Pi…

> Git can checkout only a set of files or directories How do you do this? With submodules / subtrees?

[deleted]

Re: Pijul a FOSS distributed version control system

#25

Post by jona-f »

jona-f wrote: post #6
hansvm wrote: post #2

Last I tried to run Pijul (IIRC, 2.5yrs ago), there were major, seemingly unresolvable crashes for the simplest of operations on Mac and Linux. Has it gotten better?

I tried it a few weeks ago and found it completely unusable. I do not get how they claim to be using it. I tried what I thought was the intended workflow and it's state got corrupted right away without any warnings.

Edit: had another try. It seems to work now, very interesting

Re: Pijul a FOSS distributed version control system

#27

Post by EffCompute »

jona-f wrote: post #6
hansvm wrote: post #2

Last I tried to run Pijul (IIRC, 2.5yrs ago), there were major, seemingly unresolvable crashes for the simplest of operations on Mac and Linux. Has it gotten better?

I tried it a few weeks ago and found it completely unusable. I do not get how they claim to be using it. I tried what I thought was the intended workflow and it's state got corrupted right away without any warnings.

I think EnPissant has a point regarding the overhead. Mapping semantic dependencies at the patch layer sounds great in theory, but the computational cost of resolving those graphs in a repository with thousands of changes is non-trivial.

In my work with high-performance engines, 'on-the-fly' graph resolution is usually the first thing to hit a performance wall compared to simple snapshot-based lookups. Pijul is a brilliant experiment in Category Theory applied to VCS, but until it can demonstrate that it doesn't degrade linearly with history size, Git's 'dumb' but fast snapshots will likely win the network effect battle.

Re: Pijul a FOSS distributed version control system

#30

Post by pxc »

Pijul seems great and I really want it to flourish. I love reading the blog posts when there are major updates, and its approach seems fundamentally more right than Git's (as it should— while it gets its core theory elsewhere, its UX learns from Git pain).

What I'm waiting for before I switch is mainly a really good bridge to Git. At the first couple tech companies I worked at, I led efforts to switch from Subversion to Git, and I did it by experimenting and I eventually proving a viable path using Git's built-in, two-way SVN bridge, which is excellent.

Whenever I revisit Pijul, I play with importing a giant (pathological, tbh) Git repository. Unfortunately, it runs for days and has never successfully completed for me. But the moment that bridge is good enough, I'm in! (Performance is nice but reliability is obviously the essential thing, especially when it comes to one-time operations like the initial import.)

PS: pmeunier, if you're reading this: I love your work. When Pijul can reliably import Nixpkgs, write a killer blog post about it. I'm sure it'll blow up here on HN. :)

And thanks for your work to advance the state of the art in DVCS! :)

PPS: I wonder if Pijul's fundamentally better merging behavior could become especially salient for teams (or individuals) whose codebases are seeing a lot of churn with heavy LLM use, so that it can help make automatic resolution of merge queues cheaper or easier or more reliable.

Post reply on HN