5 ms·
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 a
by 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 agoI 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.
- Izkata 3y agoThose commits you were having issues with in git, have you tried putting them into pijul to be sure it doesn't have the same problem? Because so far I have yet to understand why pijul's "set of applied patches" would do anything different than git rebase/cherry-pick. Those work by applying the diffs of each commit to the new tree. Sounds like the same thing to me, or at least close enough to result in the same conflicts.
- baq 3y agoGit does not work with patches internally. Pijul does. This is where all the differences in merging happen. If git worked with patches, git rerere wouldn’t be a thing. https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html
- deleted 3y ago[deleted]
- Ygg2 3y agoPatch commutation gives more than just interactive rebase. It gives you partial checkout with the horrible hacks like subtree.
- nemetroid 3y agoFrom what I understand, it gives you partial checkouts in the absence of ”wide” patches, which are often the point of having a monorepo.