4 ms·
I'm one of the authors. We are actually quite optimistic about Pijul's possibilities. In particular, there are a few niches where people either: (1) do not und
by pmeunier 8y ago
I'm one of the authors. We are actually quite optimistic about Pijul's possibilities. In particular, there are a few niches where people either:
(1) do not understand Git, can't learn it, still need a VCS. I have a few industrial applications in mind, not necessarily related to code.
(2) understand Git very well, and have spent too many hours debugging their failed merges, non-associativity issues, complex rebases. These users would know enough about "git rerere", for instance, to find the model of conflicts slightly absurd. For them, Git has become a source of cost in the project, and costs need to be kept under control. Again, I have at least one open source project in mind, and a handful of industrial contacts related to these use cases.
(3) many people in academia, even in computer science, collaborate on their LaTeX papers using various combinations of Dropbox and emails. This is because they are "principles people" and like to understand the principles behind what they're using. If a tool seems too complicated, it looks suspicious. But anyway, I have written papers with Git before, the "fun" of using Git often fades away as the deadline approaches.
Given the very young age of Pijul, I see this picture, and the interest many people have shown in the project, as quite promising. However, unlike what your post may suggest, I don't see Pijul as fighting against Git. Ultimately, when Pijul is ready, the two tools could become quite complementary:
- use Git (with branches, but without merges) when you need a linear history and/or a Merkel tree of your content. Git is extremely efficient in disk usage and in speed of retrieving contents. Projects like "Software Heritage" are a good example of the perfect Git-but-not-Pijul user, storage of experimental data is another one ("I've done experiment X on day Y, the results were Z").
- use Pijul when you want to collaborate efficiently on text documents, and manipulate your repository in an extremely flexible way, handle conflicts sanely, while minimising your planning and maintenance costs. Pijul will probably never be as efficient as Git in terms of disk space, but could become quite competitive in terms of merge speed. Agile teams, academic papers, are good examples.
- xearl 8y agoRegarding your niche (2): what open source project do you have in mind?
- pmeunier 8y agoOne of the largest open source repositories ever: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs
- pas 8y ago> [agile] teams yes please. git makes merges hard, and rebases are just too hard when you want to maintain a few different releases. without losing too many QALYs. (with git we [would] need to maintain a lot of branches, just to be able to have clean merge requests at the end for each big feature coming up for a release)