Pijul is a free and open source (GPL2) distributed version control system
pijul.org
pijul.org
Pijul: Version-Control Post-Git [video] - https://news.ycombinator.com/item?id=37094599 - Aug 2023 (163 comments)
Other past threads: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
git is like shaving with a straight shaving razor - alarming until you've developed your set of frequently used commands and ways to stay out of trouble.
Even I have to use git because who uses anything else? Every project that I know that used Mercurial dropped it in the hope of getting more contributions.
We have all rushed like Lemmings into Github - now owned by those nice people at Microsoft - who have used it to automate our jobs with copilot. How ridiculous that Open Source has been embraced into the clutches of the Empire on such a scale! :-) I am joking but only a bit.
Git compatibility is a great way around this problem. I have been enjoying Jujutsu lately.
So long as you require git compatibility, you're kinda stuck with git's view of what history looks like. Which is rather the point.
jj is not patch based, like pijul, but snapshots, like git.
A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub.
However, all is not lost there either: tooling like spr[1] allows you to map between the two universes.
At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop.
(I've worked with the main author of Jujutsu before. Also, having worked on Mercurial for many years, I have my biases about how source control should work. Jujutsu's workflow is very similar to Mercurial's, with some rather stunning improvements on it.)
Adjacent, I heard folks praising Forgejo for its Actions & Microsoft GitHub compatibility, but that means you are still left with the same YAML spaghetti and its other limitations. What would have been nice is something better for CI--something that prompts the project to want to switch to get a better experience. As such, while I agree with the moral reasons to switch to non-proprietary software, the reason for switching is philosophical, not philosophical + technical. I feel being a wrapper around Git or Git compatibility will likely fall in this category rather than being more compelling.
It's pretty widely not used in the games industry because its support for media files is poor, it's pretty difficult to train artists to use it, the integration with game engines is pretty poor, git LFS is a layer of complication on a system that already has UX that's difficult for artists, git LFS hosting is an additional can of worms, there's essentially no file/directory-level permissions for managing contract work (and doing so with submodules+LFS is complicated).
oh and nearly everyone hates using perforce and its clients p4v and the p4 command line, so it’s not like there’s no appetite for change. There’s very much an appetite to see Perforce unseated, because it costs money and is also bad.
If you’re getting paid then it makes some sense to worry about automation, but if you’re not, automation is good. You can do more. The community can do more. We can take on more ambitious projects.
GUIs will only ever tackle a subset of git’s functionality since if you’re already a power user you’ll be comfortable with the command line.
You definitely need a gui to do partial commits. git add -P is just horrible to use.
And as patches go through different contributors and maintainers they accumulate trailers in the form of signed-off-by and things like that. Even non-trailer (not key-value line) changelogs like: `[<initials>: fixed typo/ fixed off by one]`. And if the change is in the code then the patch content changes (not just the commit message).
The Git project is also pretty patch-based in its development. Even for those who only cares about the maintainer tree: these patches apply to this other in-flight patch series; this diff here can be applied on top of your pending patch series; this patch series is from our ongoing work at Gitlab (company); I’m resending this patch series that X did three months ago but seemed to have abandoned; etc.
My understanding is that a big part of the reason that Git is snapshot based is for reliability and for ease of checkout -- being snapshot based means Git doesn't need to replay commits every time you check things out.
That likely comes with some downsides (cherry-picking does come to mind, yes), but also seems like some serious upsides, one of the biggest one being that simplicity. It's relatively easy for me to reason about what Git is doing under the hood. I like that I'm seeing that Pijul's patch operations are associative, I like at first glance what I'm seeing it say about merges, but it's not making it clear to me what the downsides are.
Is the idea that arbitrary checkouts take longer, but that's generally fine since people don't do them very often? Or am I over-estimating how much complexity/performance costs that building a vcs like this would incur?
Pijul does a better job of recognizing that "A -> B -> C" is the same as "B' -> A' -> C".
Repo size also comes to mind on this if snapshots/caches are happening regularly/automatically, since that would mean Pijul is storing both the patches and the end states rather than computing the patches on the fly. But I guess snapshots wouldn't need to be automatic -- I'm not sure how often people actually check out arbitrary commits, maybe you could get away with only caching certain points?
There ain’t a whole lot to the first commit of Git. Some hundred lines which consists of manually preparing a commit by sending the current snapshot to the “cache” (nowadays “index”) which compresses it and then building a commit by specifying the parents and a commit message (like git-commit-tree but I don’t know if that was around back then).
Beyond that I don’t know much.
Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git?
I am a complete believer on a sound underlying model producing better results for users at a high level, but I'm not clear on how it maps through for Pijul. I think that's what they're missing in the sell - the ability to explain to devs "it will make your life easier in the following specific ways".
For example when getting my employer moved from SVN to Git I could talk to people about how much easier it was to create and then merge a temporary branch for a feature in Git. Git understand the topology of the history, knew the merge base and had better merge algos so the only pain you had was when there was an actual conflict - two people editing the same file location. It also could track renames, which were incredibly painful to merge in SVN.
Simplified example:
Persons A and B check out master branch.
Person A adds a.txt, commits and pushes.
Person B adds b.txt, commits and tries to push and...
1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again.
2) pijul will accept the change (after a pull, but no rebase) because patches A and B are independent of each other and does not matter which order they are in the history (keyword: commutation).
The value of Pijul will only start to show when you get into big three way merge scenarios. Which git users avoid like the plague because they are so nasty to deal with. Demonstrating this would need a much larger example.
edit: clarification a pull is still needed in case 2, but no rebase or merge because there isn't one for commutative patches
But is this not the right thing to do? A kernel is a complex piece of software. Changes in one place can have very non-obvious consequences in other places (think of changes that cause deadlock because locks are applied in the wrong order). Of course, it is theoretically nice if I know that a change to e.g. documentation or fixing a typo in a comment is not affecting the Ethernet driver or the virtual file system layer, but this is down to the architecture of the project - this is not something that a version control system can prove.
Given that, it seems desirable to me that the source tree has as few different variations, permutations how to get there, and so on, as possible, since this makes testing and things like bisecting for something like a broken lock or another invariant much easier.
For me "not needing to pull before pushing" is nice, but not game changing (but helpful to understand nonetheless).
It's more the cases that you allude to that we instinctively avoid in git!
I maintain a project that is a slight modification of a very active upstream repo. The changes I maintain are rather invasive. Almost every upstream commit introduces a merge conflict with my changes.
To keep myself sane I only merge/rebase when upstream releases a new version, but it still ends up sucking up a few weeks of my time every year. During those weeks, I look enviously at pijul where the conflicts would resolve down to a handful of corrections in context at the point of divergence, instead of gigantic merge conflicts obscured by thousands of piled on patches.
It would enable so many nice and less strict workflows to actually work if it ever got momentum, I've still got hope.
When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. Pijul will not.
As you say, neither will automatically check for correctness and you should run tests and CI when merging.
Pijul just removes the manual work when there is no conflict in the contents but the history is different.
But why would this normally happen? Different developers working on the same files which by chance make the same changes? Isn't that unlikely?
Not really: Pijul can record a conflict resolution as a patch, and apply it in a different context. Also, the conflict doesn't "come back", so you don't need extra hacks like rerere/jujutsu.
> Pijul just removes the manual work when there is no conflict in the contents but the history is different.
This is true, but could be confusing as our definition of conflicts isn't based on contents, but on operations, which is very different from Git (Git doesn't detect all conflicts).
This is completely false: in Pijul, any patches that could have been produced independently can be applied in any order without changing the result. There are 0 heuristics in Pijul, unlike in Git where even random line reshuffling can happen (there are examples in the "Why Pijul" section of the Pijul manual).
Obviously, deciding whether a merge has the correct semantic is Turing-complete, and Pijul doesn't try to do any of that.
If changes coming from both sources are independent, then rebase in Git is trivial as well, and there's nothing to be afraid of.
Or maybe an architectural one.
It only tracks content of files, not semantic or behavior changes.
Unless your VCS is handling CI for integrating changes on push, you really need to pull down the upstream changes first and test them combined with your code before blindly pushing.
A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines.
And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.
Pijul has a theory of textual changes, but indeed doesn't care at all about what you write in your files: that's your problem!
Darcs is older than git.
In my defense, 3-way merges are older :)
You have two repos with different history:
master -> patch a -> patch b
master -> patch b -> patch a
But the contents of the files are equal after applying both patches (in either order).
Git will consider these to be two different, Pijul thinks they're the same.
This is a simplified example. It only gets interesting when there are a lot of patches, some of which are commutative and some are not.
If the VCS knows about dependencies between patches intuitively, it could free me from having to explain it, which in the case of Git, requires following procedures that I'm unlikely to convince any of my coworkers to follow ("ohay, first, decide on the earliest point in the history from which this patch could make sense, rebase onto that....")
You and I, who are both working off of main, and who have both separate merged in a few patchsets that are relevant to our shared module of interest. We can merge and compare our branches, and the differences in terms of nursing patches without having to be rigorous about reconciling or histories.
I view anything that interferes with a push as a threat to the VCS, since it encourages developers to keep changes local and unavailable to their teammates. The only exception would be direct pushes to main.
Hmm...that seems like a feature to me, not a bug.
To me nothing of substance should happen in the repository, it should all happen in the local working directory.
¯\_(ツ)_/¯
The idea is that with pijul nothing of substance would happen on the server in this example, it is the same process that would happen if you were doing it all locally.
So it's a low-impact optimization of the fast path?
But actually, how does pijul know there are no conflicts? Textually?
https://pijul.org/manual/conflicts.html
Hmmm...yeah looks like it's purely textual. Er, no. There can be semantic conflicts that I need to resolve that do not conflict textually. The test suite needs to be green locally on my machine, and then we replace the Top of Tree wholesale with the code that passed the tests locally on my machine.
So to me this feature of pijul is clearly an anti-feature, a bug, and the git behavior is correct.
Unlike git, pijul has first class conflicts, pijul unlike git does not reject in this example.
My knowledge is limited, but from my testing that means the conflict exists in the history, at least if your merge style allows for that(similar to how in git you can choose to always rebase or use merge commits).
The conflict is resolved with a new patch.
I did not spot much in the documentation with a quick search but on the man page there is a small blurb on first class conflicts
> First-class conflicts In Pijul, conflicts are not modelled as a "failure to merge", but rather as the standard case. Specifically, conflicts happen between two changes, and are solved by one change. The resolution change solves the conflict between the same two changes, no matter if other changes have been made concurrently. Once solved, conflicts never come back.
- from https://pijul.org/
The solution would be to pull upstream changes (so you know what you are potentially pushing your changes into) and then push.
A rebase is never required in Git. (people/maintainers may disagre) but a merge will always do.
Having said that. In your scenario provided, a pull + merge/rebase will be required. It will then resolve automatically, and without conflicts. But a human has to be involved to provide a strict sequence/dag of the those commits.
In git, a cherry-pick pulls the change you're interested in off a branch, making a copy in the process. If you later merge or rebase that branch, there are two versions of it in the history, this can have practical consequences, it's not uncommon for this to generate conflicts which wouldn't be there without the cherry-pick.
In pijul, a cherry-pick is just one way to apply a patch. It's the same patch in both branches, so the history doesn't contain two versions of the change, only one. So there is no difference in the result between 'branch, cherry-pick, merge' and 'branch, merge'. Ever.
They are still a pain in Git as well. Rename a class and its usages in C# project, for example, and it randomly breaks based on some arcane heuristics.
As for actual question you posed - partial checkouts. Your artist don't need to checkout code, but can work on it art folder.
couldn't find on the "doc"... is it all rebases or all merges?
- There's an example in the "why Pijul" page of our manual where Git completely reshuffles your lines, and no "custom merge algorithm" could possibly solve it. I would be terrified if I were working on crypto/security code and I knew my VCS was doing that: https://pijul.org/manual/why_pijul.html
- Patch commutation makes all big instances small: no need for submodules, partial/shallow clones, etc. Patch commutation lets you work on a small part of the repo by cloning only the patches you're interested in, and submit patches that mechanically commute with all patches on other parts of the repo.
- Free cherry-picking: no need for strict disciplines, you can just introduce a quick fix on your local work branch, and push just that to production. When you're ready merging the rest, you won't have to solve conflicts again (no need for Git rerere/Jujutsu/…)
- Many uses of branches reduced to "just use patches": many people, especially on fast-moving projects and "early days", don't really know what they're working on, and are dragged onto solving problems they didn't plan initially. Well, Pijul lets you focus on your work, then make patches, and then separate them into branches, thanks to commutativity.
- Separation of contents and operations: this really feels like the CSS3/HTML5 of version control. In Pijul, patches have two "detachable" parts, a part describing what the patch does (as concise as "I introduced 1Tb of data", i.e. just a few bytes), and the contents (not concise: the 1Tb themselves). You don't need the data to apply a patch, so when working on large files, you can record 10 different versions, and your co-workers will only download the parts that are still alive after that. No LFS required!
- Precise modeling of conflicts: conflicts are stored in our model, not "recorded" or "artificially first class". They're literally the core of our model, the initial theoretical motivation. Patches are where you need a good tool the most, and we record them and store your precious resolutions as actual patches, so they don't come back (no "git rerere" needed, and conflict resolutions can be cherry-picked).
Now, we also have less game-changing things like:
- Accurate and super fast "blame" (which we call "credit", and which doesn't require Pijul to look at the entire history like Git does).
- Generic diffs, and therefore merge, i.e. not necessarily line-based. We haven't implemented them, but you could in theory implement AST-based diffs on top of Pijul.
This comment (that probably prompted this submission) gave me some idea at least.
As for the differences, the advantages are listed right there on the front page: commutation, merge correctness, first-class conflicts and partial clones.
Explaining these in more detail in a short example ("a blurb") is not really easy because you'd have to first set up an example three way merge (for example) and then study the behavior of git vs. pijul in detail. I recall seeing a video presentation from the Pijul authors which delved deep into this if you're interested.
But I'll give it a go anyway...
tl;dr: pijul can handle certain merge situations automatically where git requires you to manually resolve them
In practice on actual real world cases, there are lots of differences when you start working with others: even on a small project, you don't have to plan your feature branches anymore, conflicts are solved once and for all, you get free cherry-picking of bugfixes to your production branch, etc.
When your project scales, there are even more differences: commutativity handles large repos for free, patches describe large files much more efficiently than by giving their whole contents (which snapshots do).
That you definitely would have to double check because it might be that it hallucinates.
For example I look at 'sanakirja' project. The current version is 1.4.1 and the previous version was 1.4.0, and the version before that was 1.3.3:
https://crates.io/crates/sanakirja/versions
but if I look at the repository, there is no way to see any of that?
https://nest.pijul.com/pijul/sanakirja
There is "Tags" tab which is empty, and channel selection drop-down that has only "main" channel. So if I want to browse code at version 1.3.3, or see the difference between 1.3.3 and 1.4.0, or even just see what versions there are, how would I do that? To me those seem like very elementary questions, and yet reading through the manual I can find no hints toward this direction.
There is a FAQ entry that seems relevant:
> Is it possible to refer to a specific version?
> Excellent question. Since Pijul operates on patches rather than snapshots, versions are essentially unordered sets of patches. How do we communicate a specific version number to one another? We solve this by abusing elliptic curve cryptography primitives.
But its not clear at all how those "version identifiers" can be used or indeed if they are even implemented at all yet? At least based on the manual, no commands seem to take "version identifier" as argument, nor can I see them anywhere in Nest web UI.
> But its not clear at all how those "version identifiers" can be used or indeed if they are even implemented at all yet? At least based on the manual, no commands seem to take "version identifier" as argument, nor can I see them anywhere in Nest web UI.
`pijul log --state` does that, and various commands (tags, fork) do it as well. Tags are due for a redesign, since they can be made much more efficient with a really cool new design, and make Pijul a perfect hybrid between patches and snapshots.
Is there some repo that is then a good showcase?
https://nest.pijul.com/pijul/pijul:main/QL6K2ZM35B3NI.JIAAA
but the docs do not say anything about that, so it remains a mystery. also its still weird that their own projects do not use those tags, or is it just that the web UI isn't showing them properly?
However, Pijul looks interesting, nice work!
Pijul has a number of stated strengths over Git, and looks like the version history is implemented as a CRDT from my first impression. Some of the statements make me wonder how many conflicts occur in real use. If they are equal to or less than the number it produces, great. If more than what Git produces, that's a barrier to adoption, as merge conflicts are one of the biggest pains when using Git.
For me though what appears one of its biggest strengths (commutative workflow) is also its biggest drawbacks. There are so many teams that are trained in git workflow and are used to it, that getting them to switch to a completely different style of workflow in sufficient numbers will take years.
Git compatibility is a key missing feature. Git had this with Subversion, and I think it's a big reason why Git won over many of the Subversion crowd.
This means that in some cases, Pijul will correctly merge where any of the git merge strategies would create a conflict. It also means that in some other (rarer) cases, Pijul will generate a conflict where git would not: git would guess, in effect, and either get it right or get it wrong. I consider both of these things to resolve in Pijul's favor.
The Pijul model also means that conflicts preserve some crucial state which can be used to resolve the merge. A conflict is modeled as a specific data structure, not as special syntax intruded into the source file. One example of this is that conflicts can in some circumstance be resolved by applying more patches, because the conflict is metadata about the file, it isn't data in the file which screws with subsequent state changes.
I'd love to see it get 1% of the investment Github gets...
I've dropped off Github for personal projects since it's trivial to run my own git repo and git version control is built into _everything_ by default, but there are definitely annoyances I've encountered while using git that sound like they would be non-issues in Pijul, so on that level it piques my interest. On the other hand, I would want to be able to do two things before I'd seriously consider switching:
1. Self-host Pijul repos with some web interface similar to e.g. Forgejo/Gitea/Gitlab/etc (i.e. not just source control, but also a bit of project management and CI). Looks like Pijul is developed on something called "The Nest" which looks basically close enough, but the source code for that isn't public yet.
2. Install a plugin in an IDE that would let me leverage it inside the UI (with in-IDE conflict resolution)
Nevertheless, I'll assume you're not playing some weird game, and that git is trademarked, in which case I stand corrected. It's therefore safe to assume that GitHub and GitLab are allowed to use git in their trade names, according to the holder of the trademark. Unlike a notional "SVNHub", the trademark violation in those two names is quite clear, so they either have explicit permission and pay a license, or Linus (presumably) is ok with their existence.
I invite you to repeat my search. Unfortunately, the USPTO trademark database search interface is not bery intuitive, so be prepared for some trial and error if you do.
If you care about Github's dominance being an issue, walk the walk : refuse to do bug reports through it, publicly shame people and companies that use it or advertise it.
An actual blogpost :
https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
I know plenty of people & projects using Gitlab and Sourcehut (myself).
> If someone tries to publicly shame me, I'll just laugh at them.
Shaming may be wrong. You must have pretty good job security/wealth/influence to refuse Github because this can lose you many opportunities in the industry.
But that doesn't make it good, only understandable & honestly sad
I wish pmeunier all the best and I’m glad to try out pijul again once it’s a bit friendlier.
* Poor support for large/binary files. LFS is bare-minimum proof of concept.
* Poor support for large projects. Big monorepo support is definitely getting better thanks to Microsoft. Submodules are a disaster though.
How does Pijul support large files and large projects?
- Large projects: Pijul solves that easily using commutativity, you can work on partial repos natively, and your changes will commute with changes on other parts of the monorepo.
Well that's the building blocks, but Git can do that through blob filters and whatnot. It's a necessary foundation but not a complete feature. You need ways of recording which blobs should be fetched eagerly, which should be fetched on demand, maybe a way to indicate where to get the data (you might want a central store for big files like LFS).
> you can work on partial repos natively
That's very good. Does it have anything like submodules or subtrees? I kind of think they are a bad idea in general but people do use them and they can be useful in very niche cases. From the sounds of the patch-based system I guess you could do subtrees quite elegantly? Can the patches be given a "base directory"?
I don't want to seem like all this stuff should be done immediately but it does feel like these are things that kind of need to be integrated from the start to work properly, unlike in Git where they've been tacked on badly.
- Having not actually tested this in my own repos, take my insight with the appropriate grain of salt.
I've seen this exists: https://github.com/purplesyringa/PijulGit, but hasn't been updated in 5 years.
> Do files merged by Pijul always have the correct semantic? > No. Semantics depends on the particular language you’re using, and Pijul doesn’t know about them.
That makes it sounds like Pijul might sometimes merge two functionally correct versions of a file into an unfunctional, incorrect one? Is this referring to a problem git and other merge tools have as well, or is it unique to Pijul and a result of being so good at merging without conflicts that it sometimes lets through semantic conflicts?
For example, in file foo.js you export the function foo. Now, if you delete the function foo, while your colleague import it into bar.js, the resultant changes are consistent, but the program is now functionally broken.
Tho I guess it cheats existing in an image-based world (I have never used it, it's just something stuck in my memory from many years ago).
How does Pijul handle continuous integration? If there’s nothing interesting going on with that then I don’t see how the UX can be any different for publishing new versions.
It doesn't happen very often, but it is still worth running integration tests after a merge even if both branches were passing tests on their own.
The general case is where merging a patch makes the code invalid in some sense. This can range from a syntax error to a subtle bug. Version control systems don't prevent this, because they can't: in full generality, correctness is an opinion of the author.
The special case is where two patches each create a valid program, but applying both of them makes the program invalid. I think that's in the FAQ because pijul makes much of the fact that it has a sound theory of patches, as it should, that's a wonderful thing. But people commonly confuse soundness and validity, leading to questions like "so what you're saying is that a merge will never result in a borked program?".
IMHO that shouldn't be in the FAQ though, because it creates the impression you got, which is that Pijul is talking about something which might be possible in principle but which it doesn't happen to be capable of. It's just patiently explaining that Pijul can't do impossible things.
I've never understood this. AFAIK, the only use case I've ever seen for git branches is "I have some code, but don't want it going live yet". Maybe it's a WIP demo, maybe you want someone else's eyes on it, maybe you just want to back your current state up on a remote server because your laptop is going to explode.
Am I misunderstanding, and Pijul manages that without channels? Or is there a common case git branches are used that I missed?
I also don't see how it matters whether a branch is long-lived or not. What Pijul may help with is a (broken, IMHO) workflow of some Git projects where the long-standing branches are constantly rebased. This workflow is bad, but having branches in Git does not force you to (mis)use rebase.
I am not saying anything against Pijul, and maybe there is a better way than branches to manage multiple lines of development, but I'd like it to be explained. So far I cannot guess what it might be.
https://discourse.pijul.org/t/phenomenological-pijul-or-piju...
https://discourse.pijul.org/t/working-without-channels/1047/...
One of the most popular of these flows was popularized under the brand "Gitflow". Atlassian has a detailed, and critical, writeup of that here: https://www.atlassian.com/git/tutorials/comparing-workflows/...
Curious to hear about any experiences using it or thoughts about how it could be improved, extended, or compares to other systems in actual use.
- Work on the pitch and clearly state the problem this is solving instead of mainly talking about the competition. What makes this unique? Why should people care?
- Make it easy to start using this for teams. My guess is that this is where a lot of developers fail to convince others in their teams. Back in the day when I started using Git, interfacing with existing svn repositories was a key selling point for me. Likewise, I helped migrated a big cvs repository to subversion when that was new. Key selling point there: we don't loose our version history. This is a complex topic of course but I bet there are actually a lot of solutions here.
- Show that there's an ecosystem. Who is using this? What tools are there? Are there any project hosting things that I can use? Answer these questions. This is about taking away any concerns people might have about using this that are perhaps half convinced already.
Even if Pijul is better (not voicing an opinion here), it's not drastically better enough to replace Git in widespread use in the near term. The difference in day to day use is not huge.
And it is better in handling certain merge situations that are painful in git, but most programmers don't run into these often enough to care.
> What makes this unique?
It's patch based rather than snapshot based.
> Why should people care?
It avoids certain merge scenario problems that git makes painful.
> when I started using Git, interfacing with existing svn repositories was a key selling point for me
Pijul can import and export to Git (and probably others) with less problems than git vs. svn (because SVN is not distributed and had a weird branching model).
> Show that there's an ecosystem
Here's the chicken and egg problem again.
There's a "free" hosting service advertised on the front page. Or you can use it with your git hosting (but lose some of the advantages).
But GitHub and GitLab have their own CI systems and other infrastructure which isn't going to be easy or cheap to replace.
So yeah, I think that Pijul is a great piece of technology that solves a real problem we have with Git, but it's unlikely to overcome the inertia that Git{Lab,Hub,} have.
Back when git had their chicken-and-egg problem, there were hundreds if not thousands of FOSS project members independently starting threads on mailing lists about how and/or when to move to git. Many of them were already using the git web server thingy and manually syncing with svn or whatever.
Some contrarians aside, the general consensus at that time was, "Yes, that clearly does solve some real pains we currently experience on a regular basis (branching, local branching, renaming files, etc.), but how do we practically move to it?"
Practically moving to it required the infrastructure. So you had a classic chicken and egg problem, until whatever broke it (sourceforge adding git compatibility? github?).
With Pijul you have a small number of adherents who have trouble explaining the pains that Pijul addresses, much less how common those pains are in the average git project. So you haven't yet arrived at the question of how to switch to Pijul-- you're still at the question of why anyone should.
Put another way-- you don't have any potential chickens longing to be incubated in an integrated Pijul hub/CI environment. If one poofed into existence, it might hatch chickens. Then again, it might go relatively unused. So I don't have a chicken and egg problem here.
Git to Pijul is a much smaller change, it is much more difficult to justify.
And then there is the fact that popular CI solutions are tied to GitHub and GitLab which increases the friction significantly.
Having used both extensively, I don't think this is true at all. I don't see as much difference between SVN and Git, as I see between these two and Darcs/Pijul (even though Darcs has scaling issues).
The key friction getting users to switch from something they already use is articulating why that is worth doing and investing lots of time in and/or making the point that it's really easy to switch is the main job of that website. Without that, most people simply won't.
The point with an ecosystem is that there won't ever be one worth talking about unless people work hard to build one. "Build it and they will come" rarely works. This website isn't good enough to make that happen.
It's a pretty weird word for English-speakers, no argument from me there. I don't think I can explain why it's weird, but it is. I don't think that's even in the top five barriers to adoption though.
Not to mention the number of times I've tried to do a web search on an ordinary English word because someone thought that was brilliant to use as a product name and it turns up nothing because they didn't get as popular as Git or didn't have other distinctive keywords to go along with it, such as when your query not only includes "bash" but also "variable" that is unlikely to occur in a dictionary entry about the verb to bash
I'd be very surprised if there is no causal relationship between names and the chances of success, all else being equal, and the devil is in the "all else". Evidently this is not a problem with a big enough marketing budget (think Teams and Meet), but without that it may be much more economical and practical to think of a useful name
My question is: what is the motivation for making distributed VCS? Over the entire lifespan of Git the number of times I had more than one remote... I can probably count on my fingers. And I've been in infra / ops for the better part of my career. And, all those times were exceptions. I'd do it to fix something, or to move things around one time, and then remove the other remote. Other times it was my hobby projects I shared with someone in some weird way.
Most developers who aren't in infra will never see a second remote in their repositories even once in their career. It seems like developing this functionality adds a significant overhead both in terms of development effort and learning effort on the part of the user. So... why?
it depends on if you're asking about the motivations for distributed version control for linux kernel development in 2005 or the motivations for distributed version control today. git predates AWS and predates the state of the industry being that it's very easy and cost-effective for people to make central servers and web apps and things of that nature. My understanding is that "emailing a patch to a mailing list" was a more reasonable workflow then, since it piggy-backed off of people's email hosting providers (which, at that time, wasn't even "everyone using gmail", since back when git was created, gmail was invite-only; git predates gmail having open signups). Plus Subversion's branching model wasn't particularly great, so having different people work on things on different branches and giving them feedback and merging the branches when they were ready wasn't really a great experience.
The distributed nature of the version-control system facilitates branches, since a branch and a copy of the repo somewhere else are abstractly the same thing. Practically speaking, people don't push and pull code between their workstations and the network topologies are typically centralized in nature, but on a data level the distributed model is dual to the branching model, and the branching model is the thing that people actually care about. Although I _do_ think it's pretty neat that you can use a thumb drive or NAS as a remote instead of needing a server, it's probably not a core use-case for most people and most projects.
The way programming shops used to be run around the time Git appeared was what today you'd call "self-hosting". I.e. a company would have a dedicated machine(s), depending on the size of the codebase, and those would host company's Git repository. Not at the start and not now and not ever was Git primarily used as a distributed system anywhere outside of Linux kernel (and perhaps few similar projects).
At the time Git appeared it offered some practical advantages over Subversion, which was its main competitor. But those advantages weren't due to centralized / distributed distinction. Eventually, Subversion caught up to some of the features Git had.
In other words, what you say about making cost-effective servers is absolutely backwards. It's more expensive today to do that. Back in the days you paid for the physical components and electricity, while today you are also financing huge infrastructure built around physical components and electricity which you don't own.
Where AWS or the likes do win today is in situations like when your company had multiple international branches and you needed to somehow move a lot of data between them. I remember that Git was very welcome in our Israeli office (after switching from Perforce) because the other office was in Canada, and synchronization with them was painfully slow and expensive. Public cloud contributed to solving this problem, but, mostly, it "solved itself" due to network latency and bandwidth increases over time.
> The distributed nature of the version-control system facilitates branches,
This is just not true. Branches exist in both distributed and centralized VCSs. There was a time when it was "expensive" for eg. Subversion to have branches (because, oh horror! they had to be created on the central server!) but, today, the way developers work with Git, branches are almost always duplicated on the VCS server anyways. Also, the amount of traffic necessary to service the code is really tiny compared to everything else an organization does, so it's a moot point.
> Although I _do_ think it's pretty neat that you can use a thumb drive or NAS as a remote instead of needing a server,
Nothing stops you from doing the same with centralized VCS... This isn't the function of distributed / centralized... maybe in a particular VCS it's harder to do, but the reason would be that it's virtually never needed, so nobody bothered to implement that / make it easy to do.
However, this isn't really what Pijul calls "distributed": in Pijul, this term is about the work that people are doing when working collectively on a shared file. Which datastructures allow asynchronous contributions to happen? How to represent conflicts? Those questions belong to the field of distributed computing, together with things like CRDTs and leader elections.
Haha... Oh, this reminds me... there's Ada mode for Emacs that functions like that. In order to build it you need to combine multiple branches that have each its own contents (i.e. it's essentially multiple repositories combined in one) in the same checkout. It's the most bizarre way to use Git I've seen in my life (outside of total noob stuff, like when a guy wrote his entire project in .gitignore)
On a more serious note: thanks. I see now what that means. Maybe I should find time to look more into the project!
I mean, when you get hired into some programming shop, you don't go door-to-door and ask your new coworkers where their repository is, right? You open company's Wiki and it tells you where the repository is. You clone it and start working on your tickets, pull, push, rinse repeat. There's no reason for you to pull from your colleague's remote, even if it existed -- all communication is centralized and happens through the central hub, where various corporate policies wrt' working with repository are enforced (protected branches, CI pipelines etc.)
Over 99% of all developers in the world don't need this functionality. So, to say that you want to "Enable development that does not rely on a central repository" isn't answering the question. Yeah... it does, but why would you (or the authors of Pijul) care about this extremely rare case?
I'm the main author, and my answer is: because it allowed to to model with great mathematical rigor what conflicts are, how to represent them and how to treat them in the most intuitive and accessible way. The rest is indeed less essential, but still nice to have (I like doing my backups on an external hard drive using Pijul to copy my software projects).
[1]: https://darcs.net/FAQ/Performance#is-the-exponential-merge-p...
also because the language a project is written in, is one of the first things i like to check
Does it use proper SSH? (e.g. `git clone my_entry_on_ssh_config:/repo_path.git`)
also, an especial :fu: to whatever the hell is going on with SXEYMYF7P4RZM.ERRQA being a permalink to a file with a specific name, forcing me to write out in english what's going on there
If you want local configs, worst case you can update $HOME inline and make it use different dotfiles. If ssh is a must, sshfs can be a way to achieve that
That pronunciation had temporarily escaped me. I was trying to decide between a voiced postalveolar affricate d͡ʒ (hard) or voiced palatal approximant j (soft).
https://en.wikipedia.org/wiki/Voiced_postalveolar_affricate
https://en.wikipedia.org/wiki/Voiced_palatal_approximant
Edit: "hard" and "soft" seemed like the most logical way to describe what I thought was a dichotomy, particularly as it's also often used to distinguish between the voicings of "c" and "g".
Edit 2: Just read the whole FAQ (rather than searching for "pronunciation" or related terms), and noticed the "Where does the name come from?" entry, which mentions the Mexican origin, which is why "x" is "obviously" correct.
The reasoning goes like this: The word uses the Latin script in its most basic form so it's most probably some western-European language, Romance or Germanic. The phonetic structure fits Spanish the best, compared to other languages that I have any superficial knowledge on, the -ul being the most telling bit.