[HN Gopher] Pijul: A intuitive VCS unlike Git that's based on so...
___________________________________________________________________
Pijul: A intuitive VCS unlike Git that's based on sound theory of
patches
Author : pcr910303
Score : 87 points
Date : 2020-09-25 18:14 UTC (4 hours ago)
(HTM) web link (pijul.org)
(TXT) w3m dump (pijul.org)
| hinkley wrote:
| I was digging into tutorials about Git internals recently and was
| surprised to learn just how straightforward the data structures
| are. Given how stupid-simple the data is, I'm all the more
| confused about how straightforward the CLI _isn 't_.
|
| There are very few if any ways to accumulate and amplify errors
| in the system. It's no wonder Linus created a working prototype
| so fast. It's the simplest thing that could possibly work. But
| this simplicity is also the reason why binaries occupy so much
| space.
|
| A system can be so simple that there are obviously no errors, or
| so complex that no errors are obvious. In the middle ground we
| get progress by someone mathematically proving the soundness of a
| technique, and then a group of people working together to match
| the implementation verbatim to the proven technique.
|
| Pijul seems to be stepping into that middle space, but it's not
| clear to me if we're going to follow, or if something else like
| it will get us moving. I do like the concept, but as someone else
| stated, it doesn't seem to be very lively right now.
| eslaught wrote:
| If you've ever used Darcs, that might help motivate why Pijul
| is interesting. Darcs was the first system I used with an
| interactive mode, sort of like `git add -i`. Obviously that's a
| UX-side change that can be (and has been) replicated in Git.
| But at the time it was fairly mind-blowing to work that way.
|
| The other part is the theory of patches. Darcs took the lead
| here too, but the algorithms and implementation left something
| to be desired. So Pijul could be really cool if it finally gets
| this to really work.
|
| On the other hand, if I'm being honest, all of my really hairy
| merge conflicts are not things that I think could be resolved
| by this---not without changing the way we think about code from
| being about text to being about ASTs. So I'm not sure if Pijul
| would have any practical day to day consequences for me.
| Certainly, when I moved from Darcs to Git, aside from UX
| issues, I don't think I noticed any major practical headaches
| due to the loss of the theory of patches.
| hinkley wrote:
| A tool that handles a frequent but not particularly
| challenging problem is still a net win. Humans make errors.
| The more times I have to do something manually, the higher
| the likelihood I have screwed one of them up. I don't expect
| to get better at doing a task the 101st time. But I do expect
| the odds that one of them gets cocked up to climb ever so
| slightly. Better if the machine can just do it.
|
| If the majority of the code is written by middle-of-the-road
| team members, then most of the merges will be done by those
| same people. Something that never helps me with my changes
| still helps me, due to my shared responsibility for the
| project. This is an often overlooked aspect of the tool
| selection process.
| garmaine wrote:
| > On the other hand, if I'm being honest, all of my really
| hairy merge conflicts are not things that I think could be
| resolved by this---not without changing the way we think
| about code from being about text to being about ASTs.
|
| With the trend towards automatic code formatting, I don't
| think that would be difficult to do.
| riffraff wrote:
| You left out the thing that was awesome about darcs, that
| pijul could do too: real cherry pick,where picking a change
| also tracked down the other patches needed for that, you
| could literally pull whole features from one tree to another,
| not just a commit.
|
| It was marvelous with darcs.
| jcheng wrote:
| Isn't that describing `git merge <commit>`? (The whole
| point of cherry-pick being that you specifically DON'T want
| anything but the one commit)
|
| Edit: Never mind, I see that darcs patches are not
| equivalent to git commits (and maybe not to anything in
| git).
| gnufx wrote:
| > The other part is the theory of patches. Darcs took the
| lead here too, but the algorithms and implementation left
| something to be desired.
|
| For what it's worth, there's a Darcs 3 in development, with a
| new patch format/theory, thanks to the two keeping it alive.
| Find darcs 2 generally pleasant enough with a fairly large
| code base. I didn't understand the reason for not keeping the
| darcs interface with new guts for pjiul.
| btown wrote:
| I absolutely love, and recommend to any new team members, GitX
| [0] and other similar Git visualizers. It's incredibly valuable
| to be able to instantly see the Merkle Tree drawn out and say
| "oh, the reason my current HEAD isn't picking up thing X that I
| thought I'd merged in, is because thing X isn't visually an
| ancestor of my HEAD even though temporally it might have
| happened earlier than my most recent commit."
|
| I see newer engineers struggling to memorize "what Git command
| corresponds to my current situation" all the time, and they're
| missing the intuition that it's all a very simple graph under
| the hood. Github, I think, does a disservice by trying to
| present commits as a linear list - while certainly it's easier
| to code a linear visualization, it makes people feel like Git
| is impenetrable magic, when it's anything but.
|
| (Full disclosure: my love of visualizations of commit graphs
| may very much be influenced by the game Fringer [1], which was
| a formative part of my childhood!)
|
| [0] https://rowanj.github.io/gitx/
|
| [1] https://www.youtube.com/watch?v=mAV7IioO_t8
| bromonkey wrote:
| Just an FYI that GitX won't work on an up to date Mac
| acdha wrote:
| Here's the fork which I use:
|
| https://rowanj.github.io/gitx/ (`brew cask install rowanj-
| gitx`)
|
| The upstream also has some signs of life but I don't
| believe it has a stable release yet:
|
| https://github.com/gitx/gitx
| klodolph wrote:
| This is not true. Which version of GitX are you using?
| There are a number of different forks, and the one I get
| from "brew cask install rowanj-gitx" works fine on
| Catalina. It is from 2014, but it's code-signed and it's
| 64-bit.
|
| If you are using the older fork from http://gitx.frim.nl/
| then it's a 32-bit binary from 2009. That version won't
| work on current macOS versions, but it _will_ run on my
| Power Mac.
| btown wrote:
| Yep, rowanj is the one that is up to date, but to be fair
| it is not the first result on Google.
| divbzero wrote:
| Another quick visualization method built into Git:
| git log ---graph ---oneline ---decorate # ---graph
| for the visualization # ---oneline for compact commits
| # ---decorate for tag and branch refs
|
| You can also add: # ---all to include all
| branches
|
| I typically add aliases to ~/.gitconfig to use these options
| by default.
| klodolph wrote:
| Yes, the visualizers are key. My experience is that every
| team needs approximately one Git guru who can run basic
| training sessions, dictate the workflow
| (branching/tagging/etc), and fix things when they go wrong.
| Otherwise you get stick with a bunch of people memorizing Git
| commands and creating some unusable history.
|
| And while I say "Git", it's really the same situation for any
| VCS, in my experience. I think the underlying problem that a
| VCS solves is the truly complicated part here.
| aidenn0 wrote:
| Can someone with more domain knowledge than I comment on whether
| or not this project is mathematically possible?
|
| I remember the reason given for not making git patching sound was
| because all the sound algorithms known to the git author were
| slower in the common case, and only better in less common cases.
|
| Darcs is really fast for what it does, but git is way faster by
| doing less.
| samatman wrote:
| Ah I was hoping this meant the rewrite had landed.
|
| Should be soon, judging by the discourse. Looking forward to it.
| c17r wrote:
| Blog hasn't been updated since April 2019 and, I don't know if
| the repo is supposed to be browser accessible, but
| https://nest.pijul.com/pijul_org/pijul gives no useful response.
|
| Looks interesting but don't know if I'd want to rely on it.
|
| ETA: looks like their twitter account
| (https://twitter.com/pijul_org) is still active to that's a good
| thing
| lapinot wrote:
| afaik pmeunier is currently completely rewriting pijul (since
| ~1 year) privately so that he can focus on getting the
| important things right (core algorithms, repo representation)
| and not on fixing stuff. It's debatable but has been explained.
| Apparently we could see that 1.0 release soonish. Relevant
| thread: https://discourse.pijul.org/t/is-this-project-still-
| active-y...
| c17r wrote:
| Thanks, that thread was a good read-thru.
|
| I can understand why it was done the way it was done but it
| makes it difficult for outsiders to know what's up. An
| occasional "State of Pijul" blog post would be helpful. As we
| all know, the Internet is full of somewhat finished but now
| stagnant projects.
| X6S1x6Okd1st wrote:
| Last relevant comment by the Author:
|
| By the way, the main things that remain to be done before
| release are: make Git import incremental,
| at the moment it's a one-off thing that doesn't properly save
| its intermediate states. rebalance a few things
| between Pijul and Libpijul. Florent is taking care of this
| one. update the Nest for the new formats and new
| protocol. write documentation.
|
| In other words, we're really close to a release.
| albertop wrote:
| Everything old is new again. This is how Smalltalk managed
| changes. Simple and straightforward.
| computerphage wrote:
| The Pijul website says their patch model is "based on a result
| from category theory" and they link to a paper from 2013. But
| wasn't Smalltalk invented in the 70s? It seems to me that
| either the paper wasn't novel or that Smalltalk used a
| different system. Why do you believe it's the same?
| mhh__ wrote:
| In the sense that git was noticeably "better" than the
| centralized systems that came before it, is enough wrong with git
| to not use it these days? Although there are pain points with
| git, a large majority of git activities are fairly cookie-cutter
| gnufx wrote:
| That seems to suggest there weren't distributed systems before
| git (like the proprietary one git was written to replace). I
| think there's enough wrong with git after long experience with
| revision control in collaborations; I've been quote happy with
| Darcs.
| jmt_ wrote:
| Not sure the need to mention git in the title
| lytedev wrote:
| git is the de facto VCS, so comparisons to it provide a
| reasonable baseline for comparison for possible users.
| anordal wrote:
| > you can "unapply" (or "unrecord") changes made in the past,
| without having to change the identity of new patches (without
| "rebasing", in git terms).
|
| So I the identity of a patch doesn't depend on history? Nice! I
| wish git was like that. In fact, every time I rebase on master, I
| wish so.
| guitarbill wrote:
| i'm not sure if this project is different, but patches can suck
| really bad. an example of this are mercurial queues (mq). with
| no history/ancestry, the merge behaviour can be horrible. for
| even medium-size teams, it goes downhill quickly. IMO, it's
| fucking broken and a huge waste of time. of course, it's
| possible i don't get mq. but i'll take git any day of the week
| over mercurial + mq, at least git works and doesn't loose my
| work as often. (believe it or not, this is easier to do with mq
| than git (!).)
|
| maybe pijul is different, but their "conflict" doco doesn't
| fill me with confidence:
| https://pijul.org/manual/conflicts.html
| garmaine wrote:
| Mercurial is not pijul/darcs. They're fundamentally different
| at the core.
| gnufx wrote:
| > maybe pijul is different
|
| No "maybe"; that's the point. Why does modelling something
| fundamental, like conflicts, decrease confidence in the
| approach?
| garmaine wrote:
| The biggest turn off for pijul right now is I can't install it. I
| try cloning the latest source from the Nest, and it crashes
| partway through. The crashing is probabilistic, but the repo is
| large enough that it is guaranteed to happen. This problem has
| existed unfixed for a year and a half.
|
| This does not instill confidence.
| [deleted]
| pablo1 wrote:
| I can't find much talks or examples of it, any good recourses
| besides the official page?
| bifrost wrote:
| This looks kinda cool, looks like FreeBSD already supports this
| directly.
| moshimoshir wrote:
| I'm going to switch to pijul for personal work but would miss
| magit.
| kqr wrote:
| Yeah, for better or worse, Magit, Ediff, and Smerge solved
| pretty much all of my problems with Git. Now if only I could
| convince my co-workers to use Git "correctly" with the help of
| these tools...
|
| I think that's a place where things like Pijul has a chance to
| shine. Some people (perhaps rightly) are just not interested in
| learning the tooling and extra work around Git that makes Git
| even more powerful. They're relatively happy with following out
| of the box defaults, even if it doesn't lead to a great
| experience. Something like Pijul might ship with the better
| default experience.
___________________________________________________________________
(page generated 2020-09-25 23:00 UTC)