Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pijul: a distributed version control system, written in Rust (2019)

nest.pijul.com

Post reply on HN
Print view View original

11–20 of 125 posts

Re: Pijul: a distributed version control system, written in Rust (2019)

#11

Post by atombender »

hbbio wrote: post #3

How does it compare to Darcs? https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ , darcs has been around for more than 10 years and is still actively maintained.

I don't know too much about the specifics, but Pijul is based on a new "theory of patches" that is different from Darcs' and which they claim is "formally correct". Darcs always had a problem with exponential merge solutions, and Pijul apparently doesn't, partly thanks to using what they call a "conflict-tolerant" format for storing the tree. See the "Pijul for Darcs uses" at https://pijul.org/manual/why_pijul.html.

Re: Pijul: a distributed version control system, written in Rust (2019)

#13

Post by cryptonector »

hbbio wrote: post #3

How does it compare to Darcs? https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ , darcs has been around for more than 10 years and is still actively maintained.

It's comparable, apparently: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...

Re: Pijul: a distributed version control system, written in Rust (2019)

#14

Post by manojlds »

dochtman wrote: post #12

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.

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

Re: Pijul: a distributed version control system, written in Rust (2019)

#15

Post by pmeunier »

dochtman wrote: post #12

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.

would you care to justify a little bit? The latest version is 0.x, are you talking about bugs, or something else?

Re: Pijul: a distributed version control system, written in Rust (2019)

#16

Post by pmeunier »

manojlds wrote: post #14
dochtman wrote: post #12

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.

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

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.

Re: Pijul: a distributed version control system, written in Rust (2019)

#17

Post by frutiger »

pmeunier wrote: post #8
frutiger wrote: post #4

From 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…

> 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 a…

> 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].

Sure, if the two branches have diverged around the location of the patch, there will need to be a merge resolution.

Wouldn’t Pijul require the same too?

Re: Pijul: a distributed version control system, written in Rust (2019)

#18

Post by frutiger »

frant-hartm wrote: post #7
frutiger wrote: post #4

From 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…

Some people avoid merges like plague because they hate their commit history looking like a train station. Then you cherry pick and/or rebase.

I never really understood this philosophy. Separating the graph structure from how you view it is the way to go I think. e.g. `git log --no-merges`.

Re: Pijul: a distributed version control system, written in Rust (2019)

#19

Post by frutiger »

mjw1007 wrote: post #6
frutiger wrote: post #4

From 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…

But you don't want your VCS to dictate your project management. Maybe you want to apply the patch to the main development branch, let people try it there for a while, and then decide which maintained release branches should get the patch.

You can actually achieve this by making a new branch at the merge-base, cherry picking the fix from the development branch, then landing this branch into the release and development branch.

Git will record the parent commit correctly on both branches but apply no changeset to the development branch, while applying it to the release branch.

I admit the above is a bit much for most people.

Post reply on HN