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
- 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
1 Like
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.
2 Likes
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.
2 Likes
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.
3 Likes
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.
3 Likes
I recently updated my Ubuntu to 20.04, so I had the change of Bazaar becoming Breezy, and no GUI for it. Also, the Diffuse program had to change because of GTK, so I was looking at how it supports the various VCS. I found Pijul because of learning Rust, so I was looking at how to add Pijul to Diffuse.
These tools should be able to be easily extended for Pijul.
One way is to use aliases, but all of the commands need to there.
I thought I could copy the Darcs section of Diffuse, and change the details to Pijul syntax, but Pijul is missing commands. Darcs has show commands, but I can’t see anything in Pijul to tell me the state of a file. How can Diffuse show the changes in a file if there’s no way to get at the data from a file viewpoint?
I saw another thread hear that mentioned an info command, but I tried it and it does nothing. It’s also not listed in the help.
I don’t think Pijul needs all the same commands as Git, but the same information should be able to be extracted.
2 Likes
I came here to say basically this.
Pijul looks like a very cool project (thanks @joyously for telling me about it). I’m particularly excited about better cherry-picking and “conflicts as a first-class operation” - I’ve had to come up with some hacks to emulate this latter behavior (poorly) in git.
I think in order for Pijul to succeed to its full potential, it needs to be conceptually compatible with git, to the extent it can be without sacrificing its core concepts. I think this means at least the following:
- a versioning scheme with child/parent patchsets, as mentioned in the FAQ
- tags/branches that work with this scheme
- ability to import/export from/to git repositories at will
Once importing from git to pijul is available I will be happy to try it out. I don’t mind learning a new commandset, especially if it is more logical than git. nest.pijul.com looks really nice and fast also.
2 Likes
On second thought maybe this isn’t really necessary, all that is really needed is the ability to say “give me v1.2.3” and have a consistent result and consistent history for that operation.
Is it possible to refer to a specific version?
The other possibility would be to use a “set hash” function, to compute unique universal identifiers for sets of patches. The main problem with that is that not all authors will know about the same patch set: Alice and Bob producing a patch A and B (respectively) in parallel will not know about patchsets containing the other’s changes, but not theirs.
Is this really a problem? It seems like the same applies if Alice and Bob are each working in a git branch, and this is usually handled by pushing their changes to some agreed-upon central repository (or a mailing list), discussing them and merging them together.
Radicle by @pintohaps & co. can also act as a sort of compatibility layer:
We adopt the SSB social overlay paradigm to establish a peer-to-peer replication layer on top of distributed version control systems. We model this largely based on an (unmodified)
gitbackend, but strive for the protocol to be general enough to allow implementations on top of different paradigms, e.g pijul.
1 Like