
Pijul: a distributed version control system, written in Rust (2019) - tosh
https://nest.pijul.com/pijul_org/pijul
======
xoa
FWIW, this has gotten a certain amount of attention on HN over the years since
it was begun but it's instantly noticeable that patches tailed off and stopped
last June. Naturally that raises the question of "is this even still alive",
and last month the starter of the project, Pierre Meunier, posted a response
to a query about that indicating a major rewrite is in progress:

\----

[https://discourse.pijul.org/t/is-this-project-still-
active-y...](https://discourse.pijul.org/t/is-this-project-still-active-yes-
it-is/451)

> _Is Pijul still under active development?_

> _That’s right, the last patches are pretty old. A few things have happened
> since then, but they’re not public yet. This has included (1) thinking about
> new algorithms to solve our remaining problems and (2) thinking about the
> future and sustainability of the project, including its funding._

> _Another thing going on is a major rewrite of libpijul. This project was our
> first Rust project, was started in a pretty early version of Rust, on an
> incomplete theory that was only finalised in 2019. Until then it wasn’t
> clear what functions and types we wanted to expose, and how to document
> them._

> _I’m currently reorganising everything, in particular using a lot more proc-
> macros, and making it more general so that it can run on various backends
> (well, actually different variants of Sanakirja)._

> _We will hopefully have news pretty soon. I’d love to fix all the bugs in
> the Nest discussions, my hope is that many of them will simply disappear
> with the rewrite._

\----

Of course, everyone here probably knows about the risks of major rewrites,
though granted that's lessoned for something that began in the research phase
and never got close to a 1.0 and major uptake. It is a pretty interesting
project and I'd love to see it go well, so hopefully it can make the series of
transitions to something more mature and self-sustaining! For now though it
looks like things will be in a bit of stasis, and everyone will have to wait
and see what emerges on the other side.

~~~
potiuper
Rust or any procedural language seems not to be the most apt lang to do a
first implementation / rewrite of a patch theory. Patches themselves have
already been generalized to paths using HOTT ref:
[https://www.cs.cmu.edu/~rwh/papers/htpt/paper.pdf](https://www.cs.cmu.edu/~rwh/papers/htpt/paper.pdf).
The takeaway from
[https://arxiv.org/abs/1311.3903](https://arxiv.org/abs/1311.3903) is the use
of commutation to allow for push out while the HOT ref discusses
pseudocommutation regarding merges. See the footnote about commutation being
inaccurate term regarding darts model. With the addition of ojo "ghost"
deletes and pseudo edges, a formal implementation should provide a non-
exponential model/algorithm amenable for optimization.

~~~
dan-robertson
I tried to read that HOTT paper. I should preface this by saying that my
homotopy type theory knowledge is basically 0 and my topology/homotopy/algebra
knowledge is limited and rusty. Here are some notes I took as I read it:

1\. I guess I’m starting off not understanding the relevance of this paper to
distributed version control. If you have a type R for states of your
repository and patches are then paths of type a =_R b, with certain properties
of patches being certain path homotopies, surely many functions giving you a
path are somewhat boring (because a path should exist between any two
repositories). But maybe the point will be proofs about the equality and
construction of those paths. Or maybe it is to get functoriality for free.

2\. In this formalisation patches are paths so they have to form a groupoid
but if you want a distributed version control system, I think you don’t want
inverses of patches. You don’t want p . p^-1 = 1 because you want properties
like repo state = (in some sense) the composition of all patches in a set, and
if patches form a groupoid then the sets {p, p^-1} and {p, p^-1, p} are equal
(ie there isn’t a way to distinguish “apply p” from “unrevert p” and you need
some way to distinguish them if you want to be distributed. But maybe there is
some way to work around this.

3\. How to think about apd? If I think of B like a fibration of A then I guess
it makes sense but it seems weaker than that. I don’t really understand why
PathOver should depend on p (and not f too)

4\. Perhaps the paper aims to construct a patch theory where any two patches
are equal (which I guess means homotopic) under their laws. My intuition of a
patch would be that the answer to this is yes but I’m not confident. Maybe
that isn’t what the paper is about.

5\. Well I’ve heard a bunch about the univalence axiom so I’m glad to finally
get a definition of it.

6\. In 2.4.1 the definition of reversing seems wrong to me. It seems like it
only gets the right types because loop has the same type as refl. It feels
like it’s actually splitting up a path into its individual loops, reversing
them, then putting them together in the same order. On the other hand I think
I candefine a type like a : I ; b : I ; i : a = b, and then write rev a = b;
rev b = a; ap rev i = ! i. And I suppose one could define a circle type with
two points and two paths and it would look ok. So maybe the loop example
doesn’t matter because it’s all equivalent no matter how it feels.

7\. Describing patch equivalence as equivalent affect on the repo isn’t clear
to me: is the repository just the (visible) contents of the files or does it
also include hidden state related to deletions/merges/applied patches. I’m
guessing this paper needs it to be the former.

8\. It would have been nice if the paper stuck to one composition order but
whatever

9\. My concerns about reverting are slightly allayed by the paragraph about
being careful with contexts but only slightly because of the following
paragraph about coincidence. I guess invert ability is fine so long as no one
cannot actually commit a patch and its inverse

10\. Perhaps HTT gives a better framework for defining and proving things
about pseudocommutation. Maybe that is the point of this paper. I would guess
(without having read the paper) that that isn’t particularly well formalised
in category theory (but formalising a merge as a push out does seem foot to
me).

11\. Ah so inverses + pseudocommutation laws gives you merges. That seems
pretty nice. Does this let one define pseudocommutation in the categorical
approach? I guess if you have inverses and want the pseudocommutation of A
-f-> B -g-> C, you compute the push out of the span A <-!f- B -g-> C as A -h->
D <-k- C and then say the pseudocommutation is (h,!k). But my (vague)
understanding of that theory is that it wouldn’t have nontrivial inverses

12\. At the end of sec 3, I feel like I’m left wanting pseudocommutation
better defined. They say how their definition falls short but they don’t say
they will improve it. Currently it feels like they could go on to prove a
bunch of nice properties about version control systems which are allowed to
resolve merges by reverting the conflicting packages. Fingers crossed
everything will make sense soon.

13\. The “topological meaning” paragraph seems weirdly written. If the reader
knows what a universal cover is then it should say “this is the universal
cover of the circle” and then provide some actual topological colour to the
description. And if the reader doesn’t know what a universal cover is then
this information won’t add anything. Might as well have said “this is called
the fubar of the circle” and had the same effect.

14\. I would have rather had a paragraph about universality than a weird one-
liner about fundamental groups

15\. In sec 4.2 their patch types are all the same. Are we skipping some
difficulties because of this?

16\. In sec 5, why do the patches not first require that the document contains
the strings they care about? I guess that isn’t necessary.

17\. Why no homotopy that ! s<>t@i = s<>t@i or that <> is symmetric? Maybe
it’s not used. But it feels like the authors are admitting a more complex
universal cover than they intend from the semantics they give by doing that.

18\. I’m left somewhat wondering what the point is. I would say that the motto
of the category theory paper which I haven’t read but which pijul is somewhat
related to would be “patches form a category and merges are push outs. You can
use category theory to extend the category of patches into one where all push
outs exist.” For this paper I guess it’s something like “homotopy type theory
gives you some tools for working with groupoids. Here it is applied to
patches.” But otherwise I’m not really sure what the relevance is to the
implementation or correctness of a dvcs is. They don’t really provide a tool
to show that your pseudocommutation function does what it’s supposed to do and
so you don’t know that your merges work either. I guess if you could prove
that your merges are push outs, does that imply the pseudocommutation is
correct? With the category theory paper it at least gives you “correct” merges
and a good idea for how to think about patches.

~~~
feanaro
Regarding 2, why do you need the ability to distinguish these cases? After
all, those two repositories are in the same state, which is that p is applied.
The only reason you'd want to distinguish is if you want to preserve history.
What about the distributed scenario makes it special?

~~~
dan-robertson
Because a DVCS has to be distributed. If Alice writes patch p, Bob reverts it,
and Charlie unreverts it, you might (without contexts) have three people with
different states of the repo:

    
    
      Alice: {p}
      Bob: {p, !p} (or do you write this as {}?)
      Charlie: {p, !p, p} = {p, !p}? So I guess this has to be {p}
    

Suppose these people are pushing and merge if in patches to the master. Then
it has no way to distinguish these scenarios:

    
    
      A:
      1. Alice pushes; master applies p
      2. Bob pulls, reverts p, pushes. Master reverts p
      3. Charlie pulls, reapplies, pushes. Master does ??
    
      B
      1. Alice pushes; master applies p
      2. Charlie pulls
      3. Bob pulls and reverts; master reverts p
      4. Charlie pushes
    

In both cases, the state of Charlie’s repo is the same: {p}, but in case A, p
should be applied and in case B, it should not. Therefore there needs to be
some additional context (or no applying a patch and it’s inverse).

In other words, this problem is basically having a distributed set with
addition, deletion, and readdition of elements, which you can’t have in a nice
way. A distributed set that you can only add to, on the other hand, is a lot
more easy.

~~~
macintux
CRDTs have to tackle this sort of problem as well.

~~~
dan-robertson
Right. And a CRDT for a set you can add and remove from is either hard or
weird for this reason.

Also I think you don’t actually want your repo to be a CRDT because a CRDT
resolves all conflicts and that would mean merge conflicts get resolved in an
arbitrary way (leading to unexpected results and bad code). Maybe you could
say that merge conflicts don’t count as conflicts in the CRDT sense of the
word but that just feels like you’re abusing the notion of what a CRDT is.

~~~
afiori
I don't know how good of an idea CRDT would be here, but from the pijul
perspective the CRDT layer should not possibly create a conflict, in the same
way a `git fetch` should never cause a conflict (assuming well behaved
hashes).

The CRDT layer would produce a set of patches in an unmergeable state and then
pijul would have to fix it; just like git.

------
nathell
Previous discussions:

[https://news.ycombinator.com/item?id=18654958](https://news.ycombinator.com/item?id=18654958)

[https://news.ycombinator.com/item?id=18235798](https://news.ycombinator.com/item?id=18235798)

[https://news.ycombinator.com/item?id=13643025](https://news.ycombinator.com/item?id=13643025)

[https://news.ycombinator.com/item?id=10470281](https://news.ycombinator.com/item?id=10470281)

------
frutiger
From [https://pijul.org/manual/why_pijul.html#patch-
commutation](https://pijul.org/manual/why_pijul.html#patch-commutation):

> In Git, importing just a few commits from another branch is called "cherry-
> picking", and involves changing the identity (the hash) of those commits.
> This usually works the first time. However, when done again, as the
> maintainer of a stable branch probably wants to do, this often causes
> counter-intuitive conflicts.

If you're doing this in git to apply a fix to a master branch and multiple
release branches, you're doing it wrong. You should be basing the patches off
the merge-base of master and the oldest release branch you wish to land the
change into.

If you work this way, you can merge the patch cleanly into all target
branches, and this new patch becomes the new merge-base. So you can actually
continue to apply new patches without any conflicts.

~~~
pmeunier
> If you're doing this [..], you're doing it wrong. [..]

This is not 100% true (see my answer to the second part below), but the point
of Pijul is that you don't need to "do things right" to avoid the potential
problems of your version control system. In the end, a version control system
is just a tool, not a way of life or a work methodology.

Sure, there are example projects where the Git way is the best, but they are
quite rare (one example is Software Heritage [1]).

> If you work this way, you can merge the patch cleanly into all target
> branches, and this new patch becomes the new merge-base. So you can actually
> continue to apply new patches without any conflicts.

This is not actually true, and is the whole point of Pijul. In Git, your
suggestion works only as long as (1) there is never any conflict, else you
need "git rerere", and (2) 3-way merge never runs into a non-associative merge
[2].

[1] [https://www.softwareheritage.org/](https://www.softwareheritage.org/) [2]
[https://tahoe-lafs.org/~zooko/badmerge/simple.html](https://tahoe-
lafs.org/~zooko/badmerge/simple.html)

~~~
rumanator
> but the point of Pijul is that you don't need to "do things right" to avoid
> the potential problems of your version control system.

The criticism directed by the Pijul guys at git cherry-pick is actually not a
problem at all. At best, the argument made by Pijul's backers is that Pijul
implements this feature differently and in a way that arguably may be creating
a problem where in Git there is none.

~~~
pmeunier
> The criticism directed by the Pijul guys at git cherry-pick is actually not
> a problem at all.

Maybe, maybe not, but it comes with actual arguments, whereas that comment
doesn't.

~~~
rumanator
There is a clear argument that you chose to ignore: cherry-picks are patently
not a problem in Git, and the only problematic aspect is how some git users
might create their own personal problems by developing misinformed workflows
while ignoring any information on best practices. If you try to reinvent the
wheel on your own, ignore any advice or info, and end up with a badly shaped
polygonal thing then you simply can't pin the blame on your chisel.

~~~
afiori
A lot of the criticism git receive is about the stance that there is the git
way and the wrong way.

We all are super sure that git has extremely efficient workflows available; it
is just that maybe many people do not like them.

Git does not try to be a tool for everyone; it is very opinionated on how to
best use it; this obviously leaves space for less opinionated tools or even
differently opinionated tools to shine under specific use cases/scenario

------
KirinDave
I'm glad this made the front page. I and other of my friends have tried a few
times now with varying degrees of success.

For those of us pining for the days of darcs or wanting to escape the git
monoculture, Pijul is really great.

~~~
rumanator
What's the value proposition of Pijul? I mean, not being Git is not a good
reason to convince anyone to adopt it as a VCS. A tool needs to actually be
better at something and add tangible value where others may not have. What's
the absolute best reason to convince anyone to adopt Pijul?

~~~
pmeunier
It is not at all about not being Git. The absolute best reason is that Pijul
actually has the properties that people think Git has:

\- in Pijul, patches are associative: pulling B and C together after A does
the same as pulling just C after pulling A and B. Git doesn't have that
property: sometimes diff3 randomly (and silently) decides to shuffle lines
around.

\- in Pijul, patches commute. Most Git users try to simulate that by rebasing
branches, but (1) that can mean a lot of extra work for no fundamental reason
and (2) Git runs the same clunky merge algorithms to decide how to do it.

\- Pijul knows what a conflict is, whereas Git pretends to know, but then
there's "git rerere".

\- in Pijul, you can clone one subdirectory of a monorepo by just pulling the
patches related to that directory. Git can do partial clones as well, but only
with LFS and/or submodules, which are incredibly clunky and unnatural.

~~~
gcb0
> patches are associative: pulling B and C together after A does the same as
> pulling just C after pulling A and B

that makes no sense to me. DARCS also claim this, but if you have the patches
all changing the first line to a different value, obviously the last one will
dictate the final value of the first line. Which is the same as git. in what
world do you want to change orders of patches and not have the final state
change?

~~~
_nalply
Associativity is not about changing the order but about a different grouping:

    
    
        ( A B ) C = A ( B C )

~~~
jupp0r
If A, B and C are patches, you are applying C last on the left side and A last
on the right.

~~~
echo-oddly
You are wrong. Yes, on the left side B is applied to A, then C is applied to
the result (AB). However, on the right side, C is applied to B, then the
result (BC) is applied to A. A is still the left most patch in both cases. BC
could depend on (the output context of) A so it wouldn't make sense to apply A
to BC! BC is applied to A. A(BC)

~~~
jupp0r
So you are saying that applying patches is not commutative? I was assuming
A(BC) == (BC)A. What makes you think that the result should be different
depending on the order?

------
hbbio
How does it compare to Darcs?

[https://hackage.haskell.org/package/darcs](https://hackage.haskell.org/package/darcs)

Edit: Better link is [http://darcs.net/](http://darcs.net/), darcs has been
around for more than 10 years and is still actively maintained.

~~~
core-questions
The problem with Darcs, which I've seen in use, is that the tooling around it
is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain
for a bigger team, and requires a very oldschool workflow. There's a Jenkins
plugin that barely works, you have to build your own new version because
distro packages are old, etc.

Not sure whether there's any actual advantage at all.

~~~
pmeunier
Well, we (the Pijul team) are trying to learn from Darcs and not disregard
that aspect. Darcs maintainers have been super busy fixing the performance
issues, but since Pijul doesn't have those, we can invest more time in the
tooling.

Look at nest.pijul.com for example, or the satellite projects such as Thrussh
([https://cargo.io/crates/thrussh](https://cargo.io/crates/thrussh)), which
aim at making the UX as smooth as possible.

~~~
core-questions
Thanks, this is fascinating. I'd been hoping to move one of my teams away from
Darcs to Git but they're very set in their ways; gotta assume the work to
bring them to Pijul would be just as much work, but then the other teams that
use Git would also need to move. Way too much CD tooling to re-implement.

Would consider for a new project, somewhere else, though. I really miss my
perfect understanding of SVN when I get lost in some Git madness - it's
obviously way more powerful and faster but sometimes I get into merge
scenarios where I have to go edit files just to restore whatever I just did on
another branch or what-have-you. Editors papering over this with extensions to
"resolve using theirs" etc. help but seem like an ugly fix.

I am interested in [https://www.unisonweb.org/](https://www.unisonweb.org/)
which I saw here recently as storing its code in a fundamentally different way
that helps make ugly merge conflicts a thing of the past by making the on-disk
format (and therefore the revision control system) aware of some aspects of
the AST. I'd love to see this go further and have a "no conflict" merge take
place as long as two edits to a single file touched different functions and
the merged version passes some tests or whatever.

~~~
pmeunier
> gotta assume the work to bring them to Pijul would be just as much work

Not really. If they're not heavily relying on the "darcs replace" feature,
it's just the same interface. The dependencies between patches are computed
differently.

Be careful though, Pijul is still 0.12, the patch format will change.

> I'd love to see this go further and have a "no conflict" merge take place

This seems possible in a future Pijul. Right now we're just starting to get
text files right! Let's see in a few years.

------
vmchale
Last I tried it (a couple years ago), repositories got corrupted.

I'd like something to replace darcs, but so far I haven't found it.

~~~
pmeunier
Well, for a project explicitly announced as experimental (there's even a
blinking paragraph on nest.pijul.com), two years is quite a while.

The repository of Pijul itself got corrupted several times, but the last time
was certainly more than a year ago.

~~~
nieve
While that's a reasonable position in some ways I certainly don't get the
impression that I should assume Pijul is not up to the most fundamental
guarantee of an SCM: not losing my code. A page telling me why I should use
Pijul probably should explain that I shouldn't use it for anything that
matters in the most trivial of ways and yours doesn't.

[https://pijul.org/manual/why_pijul.html](https://pijul.org/manual/why_pijul.html)

~~~
vmchale
> the most fundamental guarantee of an SCM: not losing my code.

Yeah. It's not terribly useful, even as a research VCS if i end up with
corrupted repositories.

------
Myrmornis
Is there a reason it's named after the Smooth-billed Ani? (Not saying a reason
is needed!)

[https://en.wikipedia.org/wiki/Smooth-
billed_ani](https://en.wikipedia.org/wiki/Smooth-billed_ani)

~~~
pmeunier
Yes: these birds build their nests _cooperatively_.

------
dochtman
Latest commit from 7 months ago. Also, anecdotally I've heard it's not very
user friendly in practice; more like a research prototype than usable
software.

~~~
manojlds
If anything, a user friendly git is what we need, not yet another tool with
bad UX.

~~~
pmeunier
There are lots of tools out there to try and make Git simpler/more user-
friendly. There's also Mercurial, which is more user-friendly while still
using the same idea.

Pijul is meant to model asynchronous work as just that, whereas Git forces it
into a unique history. For example, in Pijul, "pull --rebase" and "pull"
produce different history, but are guaranteed by design to produce the same
result, and strictly equivalent repositories (there's actually just one
command for both).

This difference is fundamental.

------
jeffdavis
I use and like git, but I feel like I'm working against it sometimes. I much
prefer a rebase workflow with a linear history, and a chance to reorganize and
reword commits so they make more sense. Git allows this workflow, and does
quite a good job of it, but I feel nudged towards "just merge it".

If a VCS could do anything to improve the rebase workflow, that would be
pretty interesting to me.

------
jeffdavis
A more useful landing page:

[https://pijul.org/manual/why_pijul.html](https://pijul.org/manual/why_pijul.html)

------
nemetroid
The implications of Pijul are really interesting. Some of the guarantees
afforded by Pijul's model are clearly superior to those afforded by Git, but I
can't help but get the impression that Pijul is:

1\. considerably more complex under the sheets, and

2\. considerably more complex _in situations you 're going to have to deal
with as a user_.

It would be nice to read an article from someone familiar with Pijul, that
would take a look at the "ugly" (from the user's perspective) parts, and
either explain how they aren't issues in practice, or at least show how you
would handle them and argue why the benefits outweigh the costs.

For example, accurately representing repository states with files appears
difficult: the page on Pijul's theory[0] explains how Pijul does not limit the
repository to containing valid states, and mentions that "...else, we say the
file has a conflict, and presenting the state of the file to the user in an
intelligible way is not obvious.". There's an independent article about
Pijul[1] that gives some examples of how you could end up with two different
conflict states in Pijul that render into identical files.

I also had a look in the patch list for the master branch[2]. I managed to
find a few patches I couldn't understand by looking at them. I realize that
Pijul is still some ways from being ready for mass consumption, but the
selling point of Pijul is its theory of patches. The documentation for "pijul
patch"[3] notes that outputting patches as text "may lose information", and
that "the text representation is merely a pretty-printed representation, and
is not sufficient to apply the patch". This suggests to me that the difficulty
in viewing those patches is at least partially due to viewing Pijul patches
being a hard problem.

Here's an example, "Fixing a conflict with #387":
[https://nest.pijul.com/pijul_org/pijul:master/patches/6E7Kee...](https://nest.pijul.com/pijul_org/pijul:master/patches/6E7KeeqoxngvDnPvBbQDSeMvWZLN2qUMUvDnF8wADb42iZtLFWHbQSf7YAyx5D37ZuoRY3W2B5opjUJt5ZPHGUpY)

Some lines at the top appear to be for informative purposes. They reappear
later on, but slightly different (e.g. imports reordered, or with changed
whitespace), and without any color (green or red) that would indicate that
they were added or removed. They're shown in a context (e.g. line 219, 222)
where they fit in as additions together with other lines that were added,
though. The output of "pijul patch" for this patch[4] looks somewhat similar,
and likewise not very easy to digest.

I really want to like Pijul, but I'm worried that it's too powerful and
requires too much from the user. I would like to be wrong, though, so I would
really welcome an article explaining these "darker" sides.

0:
[https://pijul.org/manual/theory.html](https://pijul.org/manual/theory.html)

1: [https://jneem.github.io/pijul/](https://jneem.github.io/pijul/)

2:
[https://nest.pijul.com/pijul_org/pijul:master/patches](https://nest.pijul.com/pijul_org/pijul:master/patches)

3:
[https://pijul.org/manual/reference/patch.html](https://pijul.org/manual/reference/patch.html)

4: [https://pastebin.com/b8XT5WPE](https://pastebin.com/b8XT5WPE)

~~~
pmeunier
Hi! I'm one of the authors.

> 1\. considerably more complex under the sheets, and

Yes it is, which sometimes comforts me when I think of how long it's taken to
get a version that works reasonable well.

That said, it's also not the kind of complexity that goes against performance,
but rather the kind that makes it hard to process Pijul repositories or
patches with independent tools.

> 2\. considerably more complex in situations you're going to have to deal
> with as a user.

I've used it quite a bit, but the biggest repository I've every interacted
with is Pijul itself, which is a rather small codebase, so I don't know how
the UX scales.

I find it as easy to use as Darcs, with the caveat that patches are not always
as intelligible as in Darcs. That said, patches solving conflicts are weird
and/or wrong in Darcs, and they are quite simple in Pijul. And I believe
conflicts are the situations where you need the most simplicity and clarity.

> It would be nice to read an article from someone familiar with Pijul, [..]

That is a really nice suggestion for a blog post, it's now on my todo list.
Thanks!

> For example, accurately representing repository states with files appears
> difficult

This is unfortunately a difficulty intrinsic to the problem. Git has the same
issue, it just doesn't really show it because the conflicts that cause this
are shown in a very basic way (there's only so much that diff3 can guess).

> I managed to find a few patches I couldn't understand by looking at them.

There are two issues: one is that the Nest doesn't yet have the best
algorithms to render patches (but is likely to improve a lot with the new
version of libpijul I'm writing), and the other one is that some patches might
have been converted from a previous patch format, which makes them weird.

> I really want to like Pijul, but I'm worried that it's too powerful and
> requires too much from the user.

The goal is quite the opposite! For starters you can use it just like Git
(with branches, and only with better merges). But then when you realise you
don't need branches, everything becomes much simpler, and the tool stops
getting in your way. For large Git repositories (such as NixOS/nixpkgs on
GitHub), I wish it was using Pijul about 100% of the time I contribute or even
use my local clone.

~~~
Nullabillity
> For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was
> using Pijul about 100% of the time I contribute or even use my local clone.

That's a reasonable reaction for someone who is very familiar with Pijul, but
as a newcomer my reaction is precisely the opposite.

When trying to figure out some issue I have with some software, I quickly run
into two questions:

1\. How did the source code look for the release X that I have installed?

2\. Did patch Y make it into release X?

Git makes it trivial to answer both of those questions. Both GitHub and GitLab
show all versions as tags (by convention) that are reachable in 1-2 clicks
from the project home page, and a given commit page shows all tags that
include it.

With Pijul/Nest I have no idea where to even start. I see no tag list
anywhere[0], and patch pages look like gibberish[1].

[0]:
[https://nest.pijul.com/pmeunier/carnix:master/patches](https://nest.pijul.com/pmeunier/carnix:master/patches)

[1]:
[https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hs...](https://nest.pijul.com/pmeunier/carnix:master/patches/6gv8hsejXs2L1iKJysZ2Anz4MLReLkm4C4mxbkxHNPmitSWSn8uEkzuDEL7yosY3yCiKMSx3D8ofokM9rTL1ZKam)

~~~
pmeunier
You're basically saying the Nest is still primitive. Yes it is! It's even
blinking on its front page [https://nest.pijul.com](https://nest.pijul.com)

~~~
Nullabillity
And that's fine! I just wish I didn't have to use it (before it is _actually_
considered ready, at least).

~~~
pmeunier
You don't have to use the Nest at all, Pijul can work on your own server via
SSH, the protocol just runs commands through SSH.

~~~
Nullabillity
Sorry, guess I worded my old post poorly. I have next-to-no interest in Pijul
itself. Git is working fine for me, and the snapshot model is much clearer and
easier for me than patches anyway.

My problems only become relevant when trying to contribute to projects that
already use Pijul/Nest (Carnix).

~~~
pmeunier
> My problems only become relevant when trying to contribute to projects that
> already use Pijul/Nest (Carnix).

Well, but then you can't blame others for using their preferred tools rather
than your preferred tools. Also, Git doesn't work for Carnix, because its main
author (me) is completely overwhelmed with too many projects and wouldn't want
to add the additional project of managing Git branches.

------
svnpenn
> This website uses cookies to ensure you get the best experience on our
> website.

Thats the quickest way to get me to close the tab.

~~~
pmeunier
European laws require something like that to be said. The Nest uses cookies to
authenticate you, it doesn't even give you one if you don't log in.

~~~
Eikon
Not for functional ones. Only for tracking / advertising cookies.

------
sergiotapia
Finally, a moral DVCS.

~~~
j88439h84
Is this a graph theory joke?

