Are there plans to support pijul integrating with git, such that we could already show off some pijul advantages before transitioning whole teams?
That is, individual developers could use pijul for their local repos, and push/pull changes with an upstream central git repo.
Hi! Welcome here. There are many things to say:
First, there’s already a history import tool for GIt. If you compile Pijul with the --features git option, you’ll get a pijul git command which imports an existing Git repository into Pijul.
The patches you’ll get in Pijul will look like commits in Git, in the sense that you’ll get the same DAG of dependencies as in Git.
We could potentially write a tool to convert each patch back into a commit. However, branches aren’t explicitly saved in the history, so the most canonical option is to convert that to a flat branch in Git.
However, there is still an issue, because the identity of a patch depends on many things, and converting back and forth wouldn’t necessarily preserve patch identity. In other words, we could end up re-recording a patch we already have, which would create artificial conflicts in Pijul, since you would have two patches with different identities, doing exactly the same thing, and Pijul calls that a conflict (for a good reason: because doing the same thing in parallel with your co-authors is often a conflict).
Others have suggested that just the “other direction” would be enough, and don’t mind the conflicts. However, because they’re not using Pijul at the moment, and are Git experts, I can’t tell whether they understand the differences of what conflicts are in Git and in Pijul.
So, sorry I can’t be super helpful, but if you tell me how you’d like to work ideally despite these constraints, I can try to think of something.
Thanks for the thorough answer!
Being able to migrate existing git repos is great…
Being able to use pijul on an ongoing basis in a git team would certainly be nice, but I get the feeling that supporting that smoothly would be prohibitively expensive for now.
Instead, it’d be nice being able to demo a case in which pijul shines on our live codebase. Especially since we rely so heavily on rebase & cherrypick, it should be easier, e.g. “look how merging this big PR to both release branch and master could be half the effort!” So, for the demo use case, the sync to pijul could be slow and incomplete, and the sync to git could be jury rigged, so long as it can get the merge done.
Ok, then one thing you could do at the moment with a simple script is: you import your two Git branches into two separate Pijul repository using pijul git. This is a bit wasteful, since your branches will probably have a lot in common, but at the moment that’s all pijul git can do.
If you try to import them into the same repository, Pijul expects to find an existing channel named after a commit you have already imported. Since these channels are deleted after the import in order to save disk space, they won’t be available anymore.
Then, from one of the repositories, you can pijul pull the other, and watch how things merge gracefully… or not: Pijul doesn’t guarantee that there won’t be conflicts, it only guarantees that conflicts are correctly handled (for example, solved conflicts never come back), and that the order between lines is preserved.
This means you can trust your merges to be 100% deterministic: if Pijul doesn’t detect conflicts, it means the order is well-defined.
Note that Pijul may still have some bugs, even though we’re working hard to fix them. Also, it is sometimes a bit shy and doesn’t tell you much about errors and conflicts. We’re working on that too.