3 ms·

Jujutsu was discussed recently - https://news.ycombinator.com/item?id=36952796 https://news.ycombinator.com/item?id=36952796 IIRC it's inspired by Pijul and me

Jujutsu was discussed recently - https://news.ycombinator.com/item?id=36952796 https://news.ycombinator.com/item?id=36952796 IIRC it's inspired by Pijul and mercurial and uses git database underneath? or it's git-compatible at least.

blurbleblurble 3y ago
It doesn't support patch commutation, which in my mind is the whole point of using Pijul. https://news.ycombinator.com/item?id=29792092 https://news.ycombinator.com/item?id=29792092 Imagine being able to "toggle" features or changes quickly and easily without worrying about which order they were implemented in. Patch commutation makes that easier.
- wyldfire 3y ago
  If we can get rid of the "staging area" and resolve the ambiguities of "checkout" it would be a great step in the right direction.
  - Izkata 3y ago
    Having come from subversion, the staging area is by far my favorite part of git in day-to-day use.
    - forrestthewoods 3y ago
      Why is that? I work regularly with Mercurial and Git. The stage isn’t a huge problem or anything, but it’s super annoying and gives me zero value. TBH I think the stage is kinda dirty. Because it means you’re making a commit that has never actually existed on your machine and thus can’t have possibly been tested.
      - Izkata 3y ago
        Two things: To review the changes piece by piece before commit (git add -p) in case there's something temporary in there I forgot, and to easily exclude any such thing I never intended to commit (usually todo-style comments, sometimes hardcoding a value to trigger a bug or a popup, etc) I remember a decade ago trying mercurial and git at the same time when subversion was all I knew, and that there was something about mercurial that I found really confusing. It's long enough ago I don't remember what it was, and it may be better now, but git clicked immediately. I wouldn't be surprised if it was the way they handle commits instead of having a staging area. Also compared to subversion, the staging area is an explicit form of something that half-exists in how it tracks files for committing.
        forrestthewoods 3y ago
        Interesting. I use Mercurial in my day job and use Araxis Merge. Before pushing to CI I use Araxis to diff every file. Can make changes to the file in the tool if needed. Often reverting temp changes or spurious whitespace. This generates new changes which I then amend.
      - adastra22 3y ago
        The work around is that I stash after commit and then test the newly made patch before pushing to the repo. That describes git in a nutshell. It lives up to its name by providing stupid roundabout ways to get things done, but otherwise mostly doesn’t get in your way. Pijul is in theory better, but GitHub prevents any competition from being serious.
    - pseudalopex 3y ago
      Mercurial and others use commits how Git uses the staging area. Same benefits. Simpler interface. Fewer ways to shoot yourself in the foot.
- fl0ki 3y ago
  Sure, but in any case where the patches were independent enough to automatically apply in any order, `git rebase --interactive` would have worked just as well and has done for about two decades. It can reorder, drop, squash, amend, etc. all in your $EDITOR. The much more common limitation that hits every VCS is that patches are rarely that independent and manual merges are tedious and error-prone, but when that's not a blocker, interactive rebase is hard to beat. The biggest problem, in my experience, is that 99% of people using git have no idea just how powerful it actually is. That is a mark against git, but it is what it is, and it's a mark against engineers who refuse to learn the tools they use every day for years. Weirdest case was when I asked someone to fix up a bad merge they did that resulted in duplicate commits they didn't even notice in the log. I said just do an interactive rebase, the dude said "that is outside my operating parameters", yes really, I couldn't make that up if I tried. Dude boasted 25+ years experience and didn't know about this incredible feature, and apart from the weird robot response, this is consistent with almost everyone I talk to about almost any semi-advanced git feature.
  - blurbleblurble 3y ago
    I use `git rebase -i` all the time and it's great but it involves rewriting history, which essentially means the result is almost guaranteed to give you conflicts in any case where you want to merge or rebase it with another branch that shares some of the commits in your rebase. Whereas in Pijul history is preserved. In Pijul a "branch" (called a "channel") is just a set of applied patches. I'm still a little ignorant but if I'm not mistaken the way Pijul encodes patches, in a big graph, also means that they're more likely to be composable without conflicts in the first place. And when conflicts do arise their resolutions will be more reusable. Just today I was performance profiling various subsets of a set of changes using "git cherry-pick" and "git revert", to understand how these changes interacted and which ones gave the best results. It was fine but I had to do quite a bit of conflict resolution because some of them were based on one branch and some on another, and the resulting wouldn't even be easily mergable/reusable anyway. What if I could instead just pick a few patches I wanted to mix & match and run some benchmarks over every combination of them? Then I could pick the fastest combo without needing to worry about messing up my history? With Pijul I imagine this would be a breeze. I'm looking forward to trying it now that it's getting stable.

blurbleblurble 3y ago

It doesn't support patch commutation, which in my mind is the whole point of using Pijul. https://news.ycombinator.com/item?id=29792092 https://news.ycombinator.com/item?id=29792092 Imagine being able to "toggle" features or changes quickly and easily without worrying about which order they were implemented in. Patch commutation makes that easier.

wyldfire 3y ago
If we can get rid of the "staging area" and resolve the ambiguities of "checkout" it would be a great step in the right direction.
- Izkata 3y ago
  Having come from subversion, the staging area is by far my favorite part of git in day-to-day use.
  - forrestthewoods 3y ago
    Why is that? I work regularly with Mercurial and Git. The stage isn’t a huge problem or anything, but it’s super annoying and gives me zero value. TBH I think the stage is kinda dirty. Because it means you’re making a commit that has never actually existed on your machine and thus can’t have possibly been tested.
    - Izkata 3y ago
      Two things: To review the changes piece by piece before commit (git add -p) in case there's something temporary in there I forgot, and to easily exclude any such thing I never intended to commit (usually todo-style comments, sometimes hardcoding a value to trigger a bug or a popup, etc) I remember a decade ago trying mercurial and git at the same time when subversion was all I knew, and that there was something about mercurial that I found really confusing. It's long enough ago I don't remember what it was, and it may be better now, but git clicked immediately. I wouldn't be surprised if it was the way they handle commits instead of having a staging area. Also compared to subversion, the staging area is an explicit form of something that half-exists in how it tracks files for committing.
      - forrestthewoods 3y ago
        Interesting. I use Mercurial in my day job and use Araxis Merge. Before pushing to CI I use Araxis to diff every file. Can make changes to the file in the tool if needed. Often reverting temp changes or spurious whitespace. This generates new changes which I then amend.
    - adastra22 3y ago
      The work around is that I stash after commit and then test the newly made patch before pushing to the repo. That describes git in a nutshell. It lives up to its name by providing stupid roundabout ways to get things done, but otherwise mostly doesn’t get in your way. Pijul is in theory better, but GitHub prevents any competition from being serious.
  - pseudalopex 3y ago
    Mercurial and others use commits how Git uses the staging area. Same benefits. Simpler interface. Fewer ways to shoot yourself in the foot.
fl0ki 3y ago
Sure, but in any case where the patches were independent enough to automatically apply in any order, `git rebase --interactive` would have worked just as well and has done for about two decades. It can reorder, drop, squash, amend, etc. all in your $EDITOR. The much more common limitation that hits every VCS is that patches are rarely that independent and manual merges are tedious and error-prone, but when that's not a blocker, interactive rebase is hard to beat. The biggest problem, in my experience, is that 99% of people using git have no idea just how powerful it actually is. That is a mark against git, but it is what it is, and it's a mark against engineers who refuse to learn the tools they use every day for years. Weirdest case was when I asked someone to fix up a bad merge they did that resulted in duplicate commits they didn't even notice in the log. I said just do an interactive rebase, the dude said "that is outside my operating parameters", yes really, I couldn't make that up if I tried. Dude boasted 25+ years experience and didn't know about this incredible feature, and apart from the weird robot response, this is consistent with almost everyone I talk to about almost any semi-advanced git feature.
- blurbleblurble 3y ago
  I use `git rebase -i` all the time and it's great but it involves rewriting history, which essentially means the result is almost guaranteed to give you conflicts in any case where you want to merge or rebase it with another branch that shares some of the commits in your rebase. Whereas in Pijul history is preserved. In Pijul a "branch" (called a "channel") is just a set of applied patches. I'm still a little ignorant but if I'm not mistaken the way Pijul encodes patches, in a big graph, also means that they're more likely to be composable without conflicts in the first place. And when conflicts do arise their resolutions will be more reusable. Just today I was performance profiling various subsets of a set of changes using "git cherry-pick" and "git revert", to understand how these changes interacted and which ones gave the best results. It was fine but I had to do quite a bit of conflict resolution because some of them were based on one branch and some on another, and the resulting wouldn't even be easily mergable/reusable anyway. What if I could instead just pick a few patches I wanted to mix & match and run some benchmarks over every combination of them? Then I could pick the fastest combo without needing to worry about messing up my history? With Pijul I imagine this would be a breeze. I'm looking forward to trying it now that it's getting stable.