Exploring Pijul for a Collaborative Project - Seeking Advice on Best Practices and Workflow

Hey guys… :wave:

I am relatively new to Pijul, but I have been hearing a lot of positive things about its approach to version control and how it handles patches. I come from a background in Git and Mercurial, but I’m intrigued by how Pijul’s design seems to simplify some of the common challenges in managing distributed collaboration. That said, I still have a few questions and would appreciate some guidance from more experienced users.

One thing that stood out to me was Pijul’s patch-based system. How does this impact the day-to-day workflow compared to using branches in Git? Are there any recommended practices to ensure smooth collaboration, especially when working with multiple contributors on the same codebase?

In Git, resolving conflicts sometimes feels cumbersome, especially during rebase or merge operations. From what I’ve read, Pijul’s approach to conflict resolution is more intuitive and less error-prone. Could someone share their experiences or any tips on how to effectively manage conflicts in Pijul?

We’re planning to use Pijul in a project that also involves CI/CD pipelines (like Jenkins and GitLab). Are there existing integrations for Pijul in these systems, or would we need to build custom scripts to fit it into our workflow? Any advice on this would be really helpful.

I’ve gone through the documentation, but are there any additional resources, tutorials, or community tips that would help me and my team better understand how to maximize Pijul’s potential?

I also check this: https://discourse.pijul.org/t/pijul-git-makes-error-pristine-version-mismatch-cloning-over-the-network-can-fix-thisqlikview But I have not found any solution. Could anyone guide me about this?

Thanks in advance!

Respected communtiy member! :smiling_face_with_three_hearts:

Pijul is only theory currently, but it’s not usable for real work, only for toy projects. (But it’s fun to use in those projects.)

It is very error-prone. I accidentally pushed to a remote which contained another repo. The two repo contents got mixed up with no way to reverse it. In Git, you see that there is a conflict if you try to push a branch with the same name with different commit history. Or if you push to a different branch, then you can simply remove that branch. Also, Git has a reflog so if neither solution prevented mixing up the commits, it can be reversed with a single command.

A good use case for Pijul is when getting into version control for the first time. If somebody wants to learn it using a CLI program, then I definitely recommend Pijul over Git. However, after learning the basics, I recommend to move on to Git.

For serious work, use Git with a frontend like lazygit. (Git on the CLI is barely usable, but TUI interfaces make it fun.)

This is absolutely false, I do use Pijul in multiple teams on production projects. Everything can be undone in Pijul, even things that weren’t planned.

You seem to be complaining about unexpected behaviour compared to Git, or different command names. After you accidentally pijul pushed to the wrong repo, and then “accidentally” looked at a very long list of patches to push, and “accidentally” confirmed that you wanted to push all these patches, the unrecord command would have been useful to go back to a previous state.

A good use case for Pijul is when you work on important things and have strong requirements on the correctness of your merges. Also, if you work fast and/or on multiple things at the same time, and don’t have enough time to do Git. Or if your repos are too big and you need actual commutativity instead of merge/rebase. And indeed, if you don’t know version control Pijul is easier.

3 Likes