I'm glad this made the front page. I and other of my friends have tried a few times now with varying degrees of success.
For those of us pining for the days of darcs or wanting to escape the git monoculture, Pijul is really great.
For those of us pining for the days of darcs or wanting to escape the git monoculture, Pijul is really great.
I think it's more intuitive. Less opportunities to do silly things and some things that are punishing in git are not with patch-based version control.
Is this even relevant at all? I mean, in the user's POV the role of a VCS is to CRUD changesets and branches. As long as the user can commit their changesets and audit the DAG of past commits, who cares how the system is implemented under the hood?
That would be the role of a filesystem, and Git is a perfect distributed filesystem. A VCS also allows people to merge their changes and to detect and handle conflicts gracefully.
> who cares how the system is implemented under the hood?
Pijul is not at all about the underlying implementation of commits. Patch commutation is a radically different way of thinking about cooperation, and (1) much simpler and (2) has the potential to scale to much much larger repositories.
No, the role of the file system is not to track how changesets are organiced into branches. That's the responsibility of a VCS like Git or Mercurial or Pijul. The VCS is the interface and whatever it does with the file system is an implementation detail that's abstracted away by the VCS's interface. Similarly, patches are only relevant as an external interface of the VCS, and one that users have no good reason to use.
Oops, we just got a little bit more feature requests for a VCS than "CRUD changesets and files".
But this isn't an answer to my feature request, which was the ability to merge changes.
> Similarly, patches are only relevant as an external interface of the VCS
Why? If they're relevant as the external interface, maybe this means they model the problem better than snapshots, and should therefore be used as the implementation.
As a real example, I used to be the maintainer of a major project that had long running stable branches. This means I needed to often cherry pick bugfixes from one place to another, but cherry picks are often difficult because they can rely on prior changes you haven't yet picked. In a system like Git, you have to cherry pick things in chronological order in order to replicate each "snapshot" of the history that the original changes came from, so the merge algorithm can figure it out. What change do you start from? Who knows! You have to find the first change that can be merged properly, or by hand, and work your way from there. You effectively have to hold the hand of the tool in cases like this.
In systems like Darcs or Pijul, that does not happen. They are always able to keep track of dependencies between patches, and so a "cherry pick" naturally implies picking change A, and all dependencies of A that are not yet available. There is no notion of having to run multiple commands or whatever; it's completely transparent. From there you can either A) accept the dependent changes or B) do surgery, for example, if you need to more carefully backport things. A) is the common case in the vast majority of uses, in my experience. Where as in Git, after a long enough time, almost any uses of 'cherry pick' will immediately fail and require you to start digging and picking out historical changes -- in Darcs, it will keep working just fine, even for dozens or a hundred dependent changes you need. The default features of the tool and their UX matter a lot, here.
If you not only can't understand how different core design choices -- like the ones in Pijul or Darcs -- can impact how a user uses a tool, but even refuse to admit that a tool could ever be used any other way: that alone is a great indictment of Git's complete and total monoculture, and precisely why these tools need to keep existing. Then again, computer programmers love having stockholm syndrome and hate reading things, so maybe it doesn't matter.
Here is a good, short video explaining the theoretical underpinning of Darcs and how they impact the user (and an old side project, "Camp", that was planned to eventually become Darcs 3). It's over a decade old and just as relevant as it ever was: https://www.youtube.com/watch?v=iOGmwA5yBn0
That is, you can have a dependency even though the changes appear to be unrelated from a textual point of view.
I'm all for developing better tooling for digging into blame-history, which is more generally useful and would cover the textual dependencies between changes, but you shouldn't believe that that solves the dependency problem.
I don't think anyone believes that. The dependencies in Pijul are the minimal dependencies that make the patch application possible, they are by no means semantic (you can totally add dependencies manually, btw).
However, for the particular use case explained above (stable branches, backporting bugs), the default behaviour of Pijul already gives you something really useful.
The fact that this particular feature already exist in Pijul is not a great argument for changing the underlying data structure, which is what switching to another DVCS is.
Absolutely, the only difference is the time you'll waste managing your branches (creating, rebasing and merging them).
Then git is wrong and pijul is right for you. :)
Gits internal model is to CRUD snapshots and their relation. It would be fine if the UI would hide that but it does not. For example, gits inability to track file moves is a symptom.
That's a branch-based way to look at it.
- in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around.
- in Pijul, patches commute. Most Git users try to simulate that by rebasing branches, but (1) that can mean a lot of extra work for no fundamental reason and (2) Git runs the same clunky merge algorithms to decide how to do it.
- Pijul knows what a conflict is, whereas Git pretends to know, but then there's "git rerere".
- in Pijul, you can clone one subdirectory of a monorepo by just pulling the patches related to that directory. Git can do partial clones as well, but only with LFS and/or submodules, which are incredibly clunky and unnatural.
that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final state change?
( A B ) C = A ( B C )I redid the merge in Pijul. Pijul had a bug causing it to misread the filesystem's execute bit, and no amount of `pijul reset` would fix it. Pijul's merge conflict textual syntax was baffling as well. I think it was a stack which was pushed and popped by >>> and <<< markers, and anything under === was something I should probably remove. In the end, I did succeed in the merge, but reconciling the two projects didn't work out.
(FamiTracker was based off the MFC GUI library. It was forked to 0CC-FamiTracker, and another fork ported it to a MFC compatibility layer with a cross-platform Qt backend. The MFC compatibility layer didn't support all the functionality used by 0CC-FamiTracker.)
> Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch.
I'm not sure this would've helped in my scenario. famitracker had no public repo, and the Qt fork and 0cc-famitracker came from different Git repositories and were rooted in different subdirectories. I created a synthetic Git and Pijul history for the purpose of this merge.
But it might be helpful in other situations. I'll look into it.
> Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress.
This does seem useful.
A faster patch-based DVCS. Folks have done a good job explaining it below.
> I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS.
I dunno if I agree with this, but even if we dismiss that folks should be willing to try new things. When I was teaching folks about dcvs's back in around 2009-2010 folks were also unnecessarily skeptical of any sort of change.
> A tool needs to actually be better at something and add tangible value where others may not have
Not really though? It just needs to be different.