Git compatibility


This project has to compete with git. Git is the de-facto standard, it is backed by such companies as GitHub and it will be very hard to compete. Git has lots of tooling around it. So I guess we need this project to be interoperable with git and tooling around it with . What do I mean under interoperable? I mean it be a drop-in replacement where it is possible.
This implies:
1 compatible command-line interfaces, to enable the tools using git cli to work with it with minimal changes.
2 a folder with metadata (maybe implemented as a fuse fs) mimicking .git folder in order to make some tools working with .git folder work with pijul with minimal changes
3 interacting with git remotes and other repos

  1. i can’t see why, nor how it would be possible without hurting pijul’s advantages over git

2 and 3. a bridge between the two is planned according to previous discussions, but getting pijul to 1.0 is more important


I have a feeling that support for existing git tooling may not be as important as we might imagine. If the tool has well chosen abstractions, a lot of extra tooling becomes unnecessary. I think much of the git tooling plasters over some earlier unfixable design mistakes.

As for the gravity of GitHub’s network effects, I think that’s maintained more through platform lock-in than git dvcs lock-in. @yory mentioned the planned git-pijul-git bridge for Pijul and Nest, but GitHub also provides an api for mobile apps. Nest could use the GitHub api to sync repo stars, repo follows, user follows, issue cross-referencing, and user feed items between Nest and GitHub.

Google shut down Google Code Search some time ago. Today, many people are unhappy with the quality of GitHub’s code search. If someone were to create a smarter code search engine perhaps with some awareness of syntax and with an index including GitHub, GitLab, Nest, and more I would default to using that. Such a search engine would help break the stranglehold GitHub has as the place to find source code.


Personally I think we only need a bidirectional one-time import-export bridge pijul-git. From git so that people can abandon it without losing history, to git to give potential new users the peace of mind that if they really need to go back to git they won’t lose history.


Sorry, I’m super busy these days, and I’ve not had time to reply to this suggestion. @EvqQChOcJ47gKp, I like this proposal, and I’d love to see:

  • at least a way to setup a mirror of a Git repository, and keep it updated.
  • and, as you say, some compatibility with other tools, or at least an extra layer above Pijul to call it in a Git-compatible way.

But, as @yory said, I wonder how that last point could work without losing some of the core features of Pijul, but if you have concrete examples, here would be a good place to discuss them. Also, if you haven’t already done so, I invite you to read about the theory of Pijul (for instance Joe Neeman’s blog posts are a great start), and imagine how this could be made more Git-friendly.


A dummy pijul-to-git converter can be found here: https://nest.pijul.com/lthms/pijul-conv:master/5c4f0b3efdd449d202

It deals with one branch only, and behaves badly with conflicts (it commits the conflicts markers, etc.)

That being said, it works.


could work without losing some of the core features of Pijul, but if you have concrete examples, here would be a good place to discuss them.

My main concern are not the algos under a hood, they are under the hood and tools don’t mess with them usually, but such simple things as GUI, integrations with libraries, editors and package managers. It is an enormous problem to bring a GUI frontend like TortoiseGit (on Linux we still don’t have a one, everything we have is no match to it), and it’s better if TortoiseGit can work with Pijul if not out of the box, then with minimal changes. Though the internals of pijul, svn, hg and git are different, and the models are different, we (and what is much more important - the tools) can still think of them in the same terms of files and changes. We can lose some advantages, but it is the cost of immediately usefulness without adapting everything for working with pijul specially, which will never happen.


I was absolutely not talking about that. What is the point of using Pijul, if you want to use it with tools meant for linear history? Git is more compact and possibly theoretically faster for this particular use case.