Hi,
I understand that the ambition of Pijul team is to create a new, better VCS. However, convincing people to switch over is going to be hard, especially now that Pijul does not yet have full feature parity with, say, git.
Would it be possible to use Pijul to create a sort of “a better git-merge” command? I was thinking of something like this:
Import git repo at base commit into Pijul repo (possibly only the subset of files that have changed in either of the branches being merged/rebased).
Import both branches into Pijul as well.
Do merge and conflict resolution in Pijul.
Commit merged files back to git.
Would something like what I described above be feasible to do?
Using myself as an example, I think I’d be far more likely to consider switching to a new VCS if its benefits could be demonstrated to me on a real nasty merge I need to do in my git repo right now. And even if people decided to stay with git, they would benefit from a better merge tool and it would help to spread the word about Pijul.
Improving git was obviously the first thing we considered, given the work needed to create a new VCS.
Unfortunately, git does not save enough information to make this possible, but with an extra “helper” file to help preserve the missing info, why not?
I don’t see any obvious way to make this fast, except maybe by keeping both repositories locally, and keeping them synchronised. Of course, this would void some of the cool guarantees that come for free in pijul, and which every git user tries to simulate with git (such as using branches to simulate commutativity).
My personal answer to “switching would be hard” is that:
people are afraid of the change because they remember how Git was (and still is) hard to learn. Pijul doesn’t have that problem, even though I’ve noticed newcomers try to use it as if it were Git, for instance creating tons of branches instead of just (commuting) patches.
I do agree that Pijul doesn’t yet have all the tooling and integration that has been developed around Git, but I also believe that Git needs lots of these because it doesn’t provide any intuitive guarantee (such as associativity or commutativity), and no intuitive sane internal representation of conflicts. This means that users keep trying to make it behave sanely by adding commands (I’m looking at you, “git rerere”), whereas Pijul gives them for free. I would expect 90% of Git users to never do a manual rebase, for instance, yet wish that commits commuted. Also, I wonder what fraction of Git users have ever used more than four commands (commit, push, pull, maybe reset?). For instance, the few contributions I’ve made to NixOS, an extremely large project versioned under Git, were not as easy as they could have been because my local copy is heavily edited (with changes I’m not yet ready to share), and I need to navigate the history constantly to branch just at the right time that would allow me to both (1) contribute clean PRs and (2) have a local version with all my changes.
I didn’t really want to get into discussion of whether switching is hard or not, because these tend to get very contentious. My main question was about technical feasibility of such a tool.
Based on my own experience (and those I see around me), basic git flow is what I do 99% of the time. But then inevitably comes the time when I need to do a complex rebase onto somebody’s branch and… it may take hours. Or worse. This is exacerbated by the fact that by then I am usually out of practice with merging (see the other 99%).
With a baseline like that, waiting several minutes to create pijul repo specifically for this merge operation is not something I’d complain about, as long as the rest of it is painless. To be clear, I am not proposing to maintain two repos in parallel, I wanted Pijul repo to be transient and removed after the merge/rebase is complete.
So it sounds to me that technically this would be possible?
I believe it is, I actually thought about it a bit more since my last answer, and I don’t think you need a helper file. Technically, you would prepare a Pijul repository corresponding to the state of the Git repository just before the merge, then record patches from one branch, then from the other, and then pull patches from one branch to the other.
Also, our current git-pijul tool simulates Git’s sequential order by adding extra dependencies. I don’t think they would interfere in any way with this construction.
Last time i looked at git-pijul, it did not compile, presumably because of libpijul api changes. Do you have any plans to bring it up to date?
Also, I am wondering if it’d possible to have a bit of brain-storming discussion here on the best way to approach this. If you yourself wanted to write such a tool, how would you do it? Is literally importing a git repo into Pijul the best way to go? How hard would it be to keep two repos in parallel and incrementally sync them (in either direction)?
Have a look at my fixed and improved version of git-pijul (https://nest.pijul.com/RohanHart/git-pijul)… although that seems to have gone from the Nest for now. I assume it’s another update to the a new version of Pijul.
By improved I mean that it imports all branches at once though it doesn’t deal with merges yet. Incremental would be a good deal more work.
If I understood correctly what @pmeunier explained me, nest backups have been lost due to an issue in the hosting provider, and some information/data have been lost after that event.
