20 ms·

Pijul 1.0 Beta

347 points by Reventlov 5y ago

yairchu 5y ago
The link in "A redesign of our backend, Sanakirja, to make it significantly faster", to https://pijul.org/posts/2022-01-08-beta/2021-02-06-rethinking-sanakirja https://pijul.org/posts/2022-01-08-beta/2021-02-06-rethinkin... is broken (I get a "Not found")
- pmeunier 5y ago
  Indeed. I just fixed it.
  - cies 5y ago
    For me still NotFound
    - pmeunier 5y ago
      The linked shown above is the erroneous one, the correct one is https://pijul.org/posts/2021-02-06-rethinking-sanakirja/ https://pijul.org/posts/2021-02-06-rethinking-sanakirja/
  - tveita 5y ago
    Images in the linked articles are broken, since the links do not include a trailing "/".
- deleted 5y ago
  [deleted]
AndrewOMartin 5y ago
Pijul is a free and open source (GPL2) distributed version control system. Its distinctive feature is to be based on a theory of patches, while still being fast and scalable. This makes it easy to learn and use, without any compromise on power or features.
- mizzao 5y ago
  Thanks for the summary! Very helpful.
- yc-kraln 5y ago
  this should honestly have been on the top of the linked page.
  - abdusco 5y ago
    Clicking the `Home` button takes you to that paragraph.
eterps 5y ago
Apparently the documentation is over here: https://pijul.com/manual/getting_started.html https://pijul.com/manual/getting_started.html
- jwatt 5y ago
  Although it seems to be intentionally hidden when coming to that section of the site from the "Documentation" link on the homepage: > Coming soon. If you are interested in contributing, ... Presumably there are reasons for that, but hopefully the manual is already useful to read?
  - pmeunier 5y ago
    No particular reason, just a mistake in the links. Thanks!
cies 5y ago
While not as well documented, the storage backend used by Pijul is at least as interesting as Pijul itself. https://nest.pijul.com/pijul/sanakirja https://nest.pijul.com/pijul/sanakirja Searching the web for blogs on this topic seems the best way to learn about it.
- pmeunier 5y ago
  It is actually better documented, the design is explained in the code: https://docs.rs/sanakirja-core https://docs.rs/sanakirja-core See for instance https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/page/index.html https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/p... Sanakirja even reached a point where bugs were found only in the last few functions without comments. Writing the comments to explain exactly what each line does in all cases (there are lots of cases everywhere) fixed everything.
  - nextaccountic 5y ago
    Hi, I have some questions about Sanakirja, if you don't mind.. It stores 4kb blobs, right? Does Pijul first parse the data (copying it to other allocations), or does it use the data as is? I mean, there are some libraries like cap'n'proto[0] and rkyv[1] that can directly use the file contents as an in-memory data structure, without a deserialization step (or rather, deserialization is simply a quick validation to check the data isn't corrupted), I was wondering if Pijul did anything like that. And like, is this btree header [2] stored exactly like this on disk, and does Sanakirja exploits this to avoid further copying data? (I guess there's a trouble with compression there: to decompress you really need to write in another buffer) Also, is the I/O done with something that prevent userspace copies like mmap or io_uring, or does it eventually calls read() to copy the data to its own buffer? I want to build something like Sanakirja, but with those features to avoid copying data, so I'm wondering if there's any overlap. [0] https://github.com/capnproto/capnproto-rust https://github.com/capnproto/capnproto-rust [1] https://github.com/rkyv/rkyv https://github.com/rkyv/rkyv [2] https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/page/index.html https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/p...
gbersac 5y ago
Seems like an interesting project. It's probably impossible to fight against git nowday though. The first mover advantage of git is just too hard to overcome despite all the flaws of git.
- pas 5y ago
  Would it be possible to add the "this" as a backend to git?
  - pmeunier 5y ago
    That was obviously the first idea, but it isn't really possible. Git is meant to prevent commutation of patches, while Pijul is design to maximise it. Two-way conversion is still a goal, though.
    - pas 5y ago
      Thanks! Also congrats on 1.0! Is there a FAQ that explains this? I sort of have an intuition for what does that ("prevent commutation of patches") mean, but I don't know how complete (or useful) it is :) (I guess it has something to do with commit hashes depending on the whole chain of commits, so even if the diff between two commits is empty if they are not the same hash, they are not the same ... thing. But I don't really understand the practical implications of this. To me it seems like there's none. If two branches have the same content I'll treat them as equal. (And with some simple heuristics - like rebase is better, reverts are ugly - I'll pick the nicer one to keep. I don't really care how they ended up equal. What am I missing?)
      - pmeunier 5y ago
        Practical implications: merges are 100% predictable and deterministic, this isn't always the case in Git, sometimes lines are shuffled around (look for "associativity" in the manual). Also, you can actually cherry-pick. And rebases are not a hack.
- Ygg2 5y ago
Ygg2 5y ago
One question - what does locking a file mean in a distributed VCS like Pijul?
- pmeunier 5y ago
  Nothing. However, one could use a central server holding locks on identifiers from the distributed copies. Not mathematically elegant, but fast and convenient in some cases.
- alkonaut 5y ago
  Same as it does with binaries in git: you lock them in the central repo. Git supports this with Git-LFS. Without one blessed/central repo you can’t have meaningful locking obviously, but almost every git user works with a centralized repo.
maccard 5y ago
I downloaded this and tried to follow the documentation [0]. `pijul add` doesn't accept wildcards, instead returning a pretty unhelpful error message: > λ pijul add *.* > Error: The filename, directory name, or volume label syntax is incorrect. (o error 123) The documentation for add [1] gives no information on the format, however I put 2 and 2 together and managed to do `pijul add . -r`. The next step is `pijul record` [2] which returns another error: > Error: No identity configured yet. Please use `pijul key` to create one Ok great. I ran `pijul key` [3] (which isn't documented) which returns 0, with no output. `pijul record` still says the above, so I tried `pijul key --help` which tells me I need to run a _different_ command (`pijul key generate <LOGIN>`) but doens't tell me what `login` is supposed to be. I ran `pijul key generate <my_email>` which appears to have worked, and then `pijul record`. I actually killed it after an hour and 15 minutes, rather than waiting to see how long it would take. For reference, git add * takes about 3 minutes on the same project. Between the documentation, error messages and performance I can't see myself taking another go at this for a while. [0] https://pijul.com/manual/getting_started.html https://pijul.com/manual/getting_started.html [1] https://pijul.com/manual/reference/add.html https://pijul.com/manual/reference/add.html [2] https://pijul.com/manual/reference/record.html https://pijul.com/manual/reference/record.html [3] https://pijul.com/manual/reference/key.html https://pijul.com/manual/reference/key.html
- civilized 5y ago
  Tip on post formatting - on this line: > λ pijul add *.cpp I think you intended an asterisk to display, but it didn't, because it's being interpreted as the start of an italics markup. So you need to escape the asterisk on this line with a backslash (i.e. type \*).
  - maccard 5y ago
    I did, thanks. Fixed!
- rcthompson 5y ago
  > doesn't accept wildcards I could be misremembering, but isn't it the shell's job to expand the wildcard?
zegl 5y ago
I've been following Pijul for a long time, huge congrats to pmeunier for launching!
matesz 5y ago
I got Cloudfare error "This website has been temporarily rate limited" [1] [1] https://i.imgur.com/zZ3h24s.png https://i.imgur.com/zZ3h24s.png
- forgotmypw17 5y ago
  http://web.archive.org/web/20220119113842/https://pijul.org/posts/2022-01-08-beta/ http://web.archive.org/web/20220119113842/https://pijul.org/...
- low_tech_love 5y ago
  Not everyone is ready for HN frontpage...
  - pmeunier 5y ago
    Many of these blog posts have been on HN frontpage a number of times already, sometimes for quite a few hours… But alright, never at this rate!
  - smichael 5y ago
    Off topic: why does this happen ? I thought the point of Cloudflare is to prevent it.
fallat 5y ago
Finally, Pijul is ready. It wasn't ready 2 years ago when I was using it, but after reading that, it absolutely is. Goodbye git, you mish-mash of things.
josefrichter 5y ago
Is there any significant benefit for solo developer, please? Or "mostly solo" one?
- pmeunier 5y ago
  Fully solo: no. Mostly solo: if that means you're in small teams, yes, since you don't need to follow the rigid workflows that prevent large companies from running into Git's problems.
  - josefrichter 5y ago
    interesting. do big companies have some strict rulebooks for git? I thought everybody just follows "gitflow" model and that's enough.
    - pmeunier 5y ago
      Well, even Gitflow, while not being unreasonable, wastes engineering time. Most devs know it, so at least they don't have to relearn when onboarding, but then their VCS shapes the way they organise their work, when it should be the opposite.
  - AnthonBerg 5y ago
    I've been trying pijul fully solo. In my opinion, yes!, there are benefits. I'll try to give an example. It's been a while so I'm not 100% clear on how exactly I did it, but I had a central nix configuration Pijul repo, and the "personalized" config files for a particular machine under pijul as well – in another repo iirc? I cloned the nixos configuration files from the main repo into /etc/nixos. Then I added "personal" things like MAC addresses and an SSH key to the config file. Personal to that machine. Things that shouldn't go into the main repo. Recorded those changes into the "live machine" repo. What I ended up with was a very nice mechanism that knew about the customization entries and didn't get confused about them. I could write general changes to the machine-specific repo and easily pull them into the main repo without the version control system always getting confused about them. And vice versa. This might be possible with git. Personally I wouldn't bother and I will claim that it's not due to inexperience with git; Quite the opposite. I can certainly attest that it was very very easy and nice to do this with pijul.
junon 5y ago
Am I the only one that actually likes git? Everyone here says it's a hodgepodge of broken things but I really struggle to see how. What does Pijul do that Git can't? What does it do better?
- pmeunier 5y ago
  You're not the only one, I too like it. But there comes a time when you want your merges and rebases to work predictably (absolutely never reshuffling your lines randomly), your conflicts to be solved once and for all (without hacks like rerere!). Maybe you may also want your tool to serve your workflows and not the opposite.
  - arbaal 5y ago
    > Maybe you may also want your tool to serve your workflows and not the opposite. This sounds like you claim that pijul serves all workflows well, which would contradict my own experience. I'm so used to think in branches / PRs (to display a history and showing lineages), that I find the current way of handling channels/patches of pijul alien. Right now I would need to break my workflow in my daily operation to use pijul.
    - pmeunier 5y ago
      You can use branches in Pijul if you want, but you can't use patch commutation in Git.
    - speed_spread 5y ago
      That was a shot at git, not a claim that pijul supports all workflows. Anyway, breaking the workflow when switching tools is generally expected. It's a moment to review your assertions.
- Smaug123 5y ago
  For example, Git a) has some really upsetting merge semantics, and b) can only remember how to resolve merge conflicts you've solved before via the hack that is `git rerere` - which I call a hack because it is entirely not part of the core Git model of the world. Git views history as a series of (notionally) atomic snapshots; programmers tend to view history as a series of diffs; Git tries to supply a compatibility layer to better support how we naturally think of history, but it's such a leaky abstraction.
fractalb 5y ago
Written in Rust.
anentropic 5y ago
It needs a Homebrew release https://pijul.com/manual/installing.html https://pijul.com/manual/installing.html
ThinkBeat 5y ago
The below post conversation illustrates what is wrong with Git, and what is right with Git. I dont know much about cars. I drive a car that is boring. Automatic, ABS, whatever else. It does not spend much time at the shop. It starts, I drive it to where I need to go, turn if off. repeat. My car cannot pull a boat, it can't go off road, it can't go 0 - 60 in 3s, I cant mount a snow plow on it, i cant transport most furniture in it, It is not bullet proof, I could never race it, it does not impress the ladies, it is not very hackable, and so on and so on. A lot of people want a boring versioning system. That does not need much care, much effort, nor a careful study of its internals. and certainly not the ability to remember sequences of obscure commands and switches to get things done. Git is not a good fit as a boring versioning system. I have a couple of friends who love tinkering with their trucks or cars. They have cool cars that can do the stuff above in some combination (not bullet proof) They are fun. It is cool to get a ride. It is great to feel their passion. They want to optimize them for their needs and usually that involves making them go faster or pull more stuff, or do even bigger sand dunes and river crossings snow storms etc etc. Git is a good fit as an amazing versioning system that will be there for you when your tasks get complicated. It will allow you to perform far more use cases. The need to put in the time to learn it well is fully worth it. The problem is that Git is sold as the best versioning for all things. The vast majority have no need for its complexity. The vast majority dont care that it is distributed, or even wish it was not. They dont want 5 gig of repository history since the beginning of time. Most people treat GitHub as the server and their computer as the only client and would do just as well with SVN. In a good deal of the projects, I have worked on, I think locked files would be an easier and better solution, than merging hell. (I know that it is a wildly unpopular view) junon Am I the only one that actually likes git? Everyone here says it's a hodgepodge of broken things but I really struggle to see how. TobTobXX What made it really click for me is understanding the internals and how git works. Then all the terms like head, branch, parent, commit, tree, etc. made sense for me and the way git commands work is intuitive. I still have to look up the order of arguments for commands like git rebase, but overall, it makes complete sense. I can really recommend "Pro Git" by Chacon and Straub. I got a printed version, but it is also available under the CC-NC-SA here: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
- 5y ago
durandal1 5y ago
Of course any use can add any alias they want, but I hope they consider naming their command line tool something that is easier to type. It may sound silly, bit it's UX for the command line - names that encourage rolling motions or at least alternating sides of the keyboard has a significant ergonomic advantage.
ngrilly 5y ago
How do you handle code reviews with Pijul and Nest?
nyanpasu64 5y ago
I ran `cargo install pijul --version '1.0.0-beta'`, but can't find a `pijul git` command to test importing Git repositories. It prints "No such subcommand: "git"".
- dilap 5y ago
  You want cargo install pijul --version '1.0.0-beta' --features git (pmeunier, if you're reading this, you should probably make that the default on the webpage -- i think trying to import a git repo will be a very common "kick the tires" first use case)

347 points by Reventlov 5y ago

The link in "A redesign of our backend, Sanakirja, to make it significantly faster", to https://pijul.org/posts/2022-01-08-beta/2021-02-06-rethinking-sanakirja https://pijul.org/posts/2022-01-08-beta/2021-02-06-rethinkin... is broken (I get a "Not found")

pmeunier 5y ago
Indeed. I just fixed it.
- cies 5y ago
  For me still NotFound
  - pmeunier 5y ago
    The linked shown above is the erroneous one, the correct one is https://pijul.org/posts/2021-02-06-rethinking-sanakirja/ https://pijul.org/posts/2021-02-06-rethinking-sanakirja/
- tveita 5y ago
  Images in the linked articles are broken, since the links do not include a trailing "/".
deleted 5y ago
[deleted]

AndrewOMartin 5y ago

Pijul is a free and open source (GPL2) distributed version control system. Its distinctive feature is to be based on a theory of patches, while still being fast and scalable. This makes it easy to learn and use, without any compromise on power or features.

mizzao 5y ago
Thanks for the summary! Very helpful.
yc-kraln 5y ago
this should honestly have been on the top of the linked page.
- abdusco 5y ago
  Clicking the `Home` button takes you to that paragraph.

eterps 5y ago

Apparently the documentation is over here: https://pijul.com/manual/getting_started.html https://pijul.com/manual/getting_started.html

jwatt 5y ago
Although it seems to be intentionally hidden when coming to that section of the site from the "Documentation" link on the homepage: > Coming soon. If you are interested in contributing, ... Presumably there are reasons for that, but hopefully the manual is already useful to read?
- pmeunier 5y ago
  No particular reason, just a mistake in the links. Thanks!

cies 5y ago

While not as well documented, the storage backend used by Pijul is at least as interesting as Pijul itself. https://nest.pijul.com/pijul/sanakirja https://nest.pijul.com/pijul/sanakirja Searching the web for blogs on this topic seems the best way to learn about it.

pmeunier 5y ago
It is actually better documented, the design is explained in the code: https://docs.rs/sanakirja-core https://docs.rs/sanakirja-core See for instance https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/page/index.html https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/p... Sanakirja even reached a point where bugs were found only in the last few functions without comments. Writing the comments to explain exactly what each line does in all cases (there are lots of cases everywhere) fixed everything.
- nextaccountic 5y ago
  Hi, I have some questions about Sanakirja, if you don't mind.. It stores 4kb blobs, right? Does Pijul first parse the data (copying it to other allocations), or does it use the data as is? I mean, there are some libraries like cap'n'proto[0] and rkyv[1] that can directly use the file contents as an in-memory data structure, without a deserialization step (or rather, deserialization is simply a quick validation to check the data isn't corrupted), I was wondering if Pijul did anything like that. And like, is this btree header [2] stored exactly like this on disk, and does Sanakirja exploits this to avoid further copying data? (I guess there's a trouble with compression there: to decompress you really need to write in another buffer) Also, is the I/O done with something that prevent userspace copies like mmap or io_uring, or does it eventually calls read() to copy the data to its own buffer? I want to build something like Sanakirja, but with those features to avoid copying data, so I'm wondering if there's any overlap. [0] https://github.com/capnproto/capnproto-rust https://github.com/capnproto/capnproto-rust [1] https://github.com/rkyv/rkyv https://github.com/rkyv/rkyv [2] https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/page/index.html https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/p...

gbersac 5y ago

Seems like an interesting project. It's probably impossible to fight against git nowday though. The first mover advantage of git is just too hard to overcome despite all the flaws of git.

pas 5y ago
Would it be possible to add the "this" as a backend to git?
- pmeunier 5y ago
  That was obviously the first idea, but it isn't really possible. Git is meant to prevent commutation of patches, while Pijul is design to maximise it. Two-way conversion is still a goal, though.
  - pas 5y ago
    Thanks! Also congrats on 1.0! Is there a FAQ that explains this? I sort of have an intuition for what does that ("prevent commutation of patches") mean, but I don't know how complete (or useful) it is :) (I guess it has something to do with commit hashes depending on the whole chain of commits, so even if the diff between two commits is empty if they are not the same hash, they are not the same ... thing. But I don't really understand the practical implications of this. To me it seems like there's none. If two branches have the same content I'll treat them as equal. (And with some simple heuristics - like rebase is better, reverts are ugly - I'll pick the nicer one to keep. I don't really care how they ended up equal. What am I missing?)
    - pmeunier 5y ago
      Practical implications: merges are 100% predictable and deterministic, this isn't always the case in Git, sometimes lines are shuffled around (look for "associativity" in the manual). Also, you can actually cherry-pick. And rebases are not a hack.
Ygg2 5y ago

Ygg2 5y ago

One question - what does locking a file mean in a distributed VCS like Pijul?

pmeunier 5y ago
Nothing. However, one could use a central server holding locks on identifiers from the distributed copies. Not mathematically elegant, but fast and convenient in some cases.
alkonaut 5y ago
Same as it does with binaries in git: you lock them in the central repo. Git supports this with Git-LFS. Without one blessed/central repo you can’t have meaningful locking obviously, but almost every git user works with a centralized repo.

maccard 5y ago

I downloaded this and tried to follow the documentation [0]. `pijul add` doesn't accept wildcards, instead returning a pretty unhelpful error message: > λ pijul add *.* > Error: The filename, directory name, or volume label syntax is incorrect. (o error 123) The documentation for add [1] gives no information on the format, however I put 2 and 2 together and managed to do `pijul add . -r`. The next step is `pijul record` [2] which returns another error: > Error: No identity configured yet. Please use `pijul key` to create one Ok great. I ran `pijul key` [3] (which isn't documented) which returns 0, with no output. `pijul record` still says the above, so I tried `pijul key --help` which tells me I need to run a _different_ command (`pijul key generate <LOGIN>`) but doens't tell me what `login` is supposed to be. I ran `pijul key generate <my_email>` which appears to have worked, and then `pijul record`. I actually killed it after an hour and 15 minutes, rather than waiting to see how long it would take. For reference, git add * takes about 3 minutes on the same project. Between the documentation, error messages and performance I can't see myself taking another go at this for a while. [0] https://pijul.com/manual/getting_started.html https://pijul.com/manual/getting_started.html [1] https://pijul.com/manual/reference/add.html https://pijul.com/manual/reference/add.html [2] https://pijul.com/manual/reference/record.html https://pijul.com/manual/reference/record.html [3] https://pijul.com/manual/reference/key.html https://pijul.com/manual/reference/key.html

civilized 5y ago
Tip on post formatting - on this line: > λ pijul add *.cpp I think you intended an asterisk to display, but it didn't, because it's being interpreted as the start of an italics markup. So you need to escape the asterisk on this line with a backslash (i.e. type \*).
- maccard 5y ago
  I did, thanks. Fixed!
rcthompson 5y ago
> doesn't accept wildcards I could be misremembering, but isn't it the shell's job to expand the wildcard?

zegl 5y ago

I've been following Pijul for a long time, huge congrats to pmeunier for launching!

matesz 5y ago

I got Cloudfare error "This website has been temporarily rate limited" [1] [1] https://i.imgur.com/zZ3h24s.png https://i.imgur.com/zZ3h24s.png

forgotmypw17 5y ago
http://web.archive.org/web/20220119113842/https://pijul.org/posts/2022-01-08-beta/ http://web.archive.org/web/20220119113842/https://pijul.org/...
low_tech_love 5y ago
Not everyone is ready for HN frontpage...
- pmeunier 5y ago
  Many of these blog posts have been on HN frontpage a number of times already, sometimes for quite a few hours… But alright, never at this rate!
- smichael 5y ago
  Off topic: why does this happen ? I thought the point of Cloudflare is to prevent it.

fallat 5y ago

Finally, Pijul is ready. It wasn't ready 2 years ago when I was using it, but after reading that, it absolutely is. Goodbye git, you mish-mash of things.

josefrichter 5y ago

Is there any significant benefit for solo developer, please? Or "mostly solo" one?

pmeunier 5y ago
Fully solo: no. Mostly solo: if that means you're in small teams, yes, since you don't need to follow the rigid workflows that prevent large companies from running into Git's problems.
- josefrichter 5y ago
  interesting. do big companies have some strict rulebooks for git? I thought everybody just follows "gitflow" model and that's enough.
  - pmeunier 5y ago
    Well, even Gitflow, while not being unreasonable, wastes engineering time. Most devs know it, so at least they don't have to relearn when onboarding, but then their VCS shapes the way they organise their work, when it should be the opposite.
- AnthonBerg 5y ago
  I've been trying pijul fully solo. In my opinion, yes!, there are benefits. I'll try to give an example. It's been a while so I'm not 100% clear on how exactly I did it, but I had a central nix configuration Pijul repo, and the "personalized" config files for a particular machine under pijul as well – in another repo iirc? I cloned the nixos configuration files from the main repo into /etc/nixos. Then I added "personal" things like MAC addresses and an SSH key to the config file. Personal to that machine. Things that shouldn't go into the main repo. Recorded those changes into the "live machine" repo. What I ended up with was a very nice mechanism that knew about the customization entries and didn't get confused about them. I could write general changes to the machine-specific repo and easily pull them into the main repo without the version control system always getting confused about them. And vice versa. This might be possible with git. Personally I wouldn't bother and I will claim that it's not due to inexperience with git; Quite the opposite. I can certainly attest that it was very very easy and nice to do this with pijul.

junon 5y ago

Am I the only one that actually likes git? Everyone here says it's a hodgepodge of broken things but I really struggle to see how. What does Pijul do that Git can't? What does it do better?

pmeunier 5y ago
You're not the only one, I too like it. But there comes a time when you want your merges and rebases to work predictably (absolutely never reshuffling your lines randomly), your conflicts to be solved once and for all (without hacks like rerere!). Maybe you may also want your tool to serve your workflows and not the opposite.
- arbaal 5y ago
  > Maybe you may also want your tool to serve your workflows and not the opposite. This sounds like you claim that pijul serves all workflows well, which would contradict my own experience. I'm so used to think in branches / PRs (to display a history and showing lineages), that I find the current way of handling channels/patches of pijul alien. Right now I would need to break my workflow in my daily operation to use pijul.
  - pmeunier 5y ago
    You can use branches in Pijul if you want, but you can't use patch commutation in Git.
  - speed_spread 5y ago
    That was a shot at git, not a claim that pijul supports all workflows. Anyway, breaking the workflow when switching tools is generally expected. It's a moment to review your assertions.
Smaug123 5y ago
For example, Git a) has some really upsetting merge semantics, and b) can only remember how to resolve merge conflicts you've solved before via the hack that is `git rerere` - which I call a hack because it is entirely not part of the core Git model of the world. Git views history as a series of (notionally) atomic snapshots; programmers tend to view history as a series of diffs; Git tries to supply a compatibility layer to better support how we naturally think of history, but it's such a leaky abstraction.

fractalb 5y ago

Written in Rust.

anentropic 5y ago

It needs a Homebrew release https://pijul.com/manual/installing.html https://pijul.com/manual/installing.html

ThinkBeat 5y ago

The below post conversation illustrates what is wrong with Git, and what is right with Git. I dont know much about cars. I drive a car that is boring. Automatic, ABS, whatever else. It does not spend much time at the shop. It starts, I drive it to where I need to go, turn if off. repeat. My car cannot pull a boat, it can't go off road, it can't go 0 - 60 in 3s, I cant mount a snow plow on it, i cant transport most furniture in it, It is not bullet proof, I could never race it, it does not impress the ladies, it is not very hackable, and so on and so on. A lot of people want a boring versioning system. That does not need much care, much effort, nor a careful study of its internals. and certainly not the ability to remember sequences of obscure commands and switches to get things done. Git is not a good fit as a boring versioning system. I have a couple of friends who love tinkering with their trucks or cars. They have cool cars that can do the stuff above in some combination (not bullet proof) They are fun. It is cool to get a ride. It is great to feel their passion. They want to optimize them for their needs and usually that involves making them go faster or pull more stuff, or do even bigger sand dunes and river crossings snow storms etc etc. Git is a good fit as an amazing versioning system that will be there for you when your tasks get complicated. It will allow you to perform far more use cases. The need to put in the time to learn it well is fully worth it. The problem is that Git is sold as the best versioning for all things. The vast majority have no need for its complexity. The vast majority dont care that it is distributed, or even wish it was not. They dont want 5 gig of repository history since the beginning of time. Most people treat GitHub as the server and their computer as the only client and would do just as well with SVN. In a good deal of the projects, I have worked on, I think locked files would be an easier and better solution, than merging hell. (I know that it is a wildly unpopular view) junon Am I the only one that actually likes git? Everyone here says it's a hodgepodge of broken things but I really struggle to see how. TobTobXX What made it really click for me is understanding the internals and how git works. Then all the terms like head, branch, parent, commit, tree, etc. made sense for me and the way git commands work is intuitive. I still have to look up the order of arguments for commands like git rebase, but overall, it makes complete sense. I can really recommend "Pro Git" by Chacon and Straub. I got a printed version, but it is also available under the CC-NC-SA here: https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

5y ago

durandal1 5y ago

Of course any use can add any alias they want, but I hope they consider naming their command line tool something that is easier to type. It may sound silly, bit it's UX for the command line - names that encourage rolling motions or at least alternating sides of the keyboard has a significant ergonomic advantage.

ngrilly 5y ago

How do you handle code reviews with Pijul and Nest?

nyanpasu64 5y ago

I ran `cargo install pijul --version '1.0.0-beta'`, but can't find a `pijul git` command to test importing Git repositories. It prints "No such subcommand: "git"".

dilap 5y ago
You want cargo install pijul --version '1.0.0-beta' --features git (pmeunier, if you're reading this, you should probably make that the default on the webpage -- i think trying to import a git repo will be a very common "kick the tires" first use case)