4 ms·

> Can someone give me a real world example (person a makes X change, person b makes y change etc. etc.) that would work better in Pijul than Git? Simplified ex

• hombrebuffalo 3y ago
  Does that only apply to adding new files? The changes in commit A could affect the behavior of the changes in commit B even if they are different files.
  • exDM69 3y ago
    No, it applies to everything. If adding patches A and B (same or different files) will lead to same result regardless of which order they are applied, they are called "commutative" and pijul won't care which order they are in your history. It only tracks content of files, not semantic or behavior changes.
• ynniv 3y ago
  git can already do this as long as there isn't a conflict. Maybe pijul has better three way conflict resolution, but those can be risky, and avoiding those rare situations wouldn't offset the vast amount of tooling that got has.
  • baq 3y ago
    pijul has a lot of theory and engineering to figure them out, dealing with them better than git is one of the major reasons it exists at all, and darcs before it.
    • thesz 3y ago
      > darcs before it. Darcs is older than git.
      • baq 3y ago
        True. In my defense, 3-way merges are older :)
  • ajoberstar 3y ago
    Git would make you merge or rebase, but yes there wouldn't be a conflict. They're saying Pijul would let you directly push without having to deal with the diverging histories.
    • CuriousCosmic 3y ago
      Which tbh is a bad thing. Just because change a doesn't textually touch change b doesn't mean they don't interact. Unless your VCS is handling CI for integrating changes on push, you really need to pull down the upstream changes first and test them combined with your code before blindly pushing.
      • ykonstant 3y ago
        That seems like a very important point; how does pijul deal with such "effects at a distance"?
        • pmeunier 3y ago
          By not being a CI tool, nor claiming to solve such Turing-complete problems. Pijul has a theory of textual changes, but indeed doesn't care at all about what you write in your files: that's your problem!
• mpweiher 3y ago
  > git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. Hmm...that seems like a feature to me, not a bug. To me nothing of substance should happen in the repository, it should all happen in the local working directory. ¯\_(ツ)_/¯
  • bluepanda1234 3y ago
    Was going to say exactly this, though I do wonder if it's just me being too set in my thinking around how I think version control should work.
  • davorak 3y ago
    > To me nothing of substance should happen in the repository, The idea is that with pijul nothing of substance would happen on the server in this example, it is the same process that would happen if you were doing it all locally.
    • mpweiher 3y ago
      Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. So it's a low-impact optimization of the fast path? But actually, how does pijul know there are no conflicts? Textually? https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html Hmmm...yeah looks like it's purely textual. Er, no. There can be semantic conflicts that I need to resolve that do not conflict textually. The test suite needs to be green locally on my machine, and then we replace the Top of Tree wholesale with the code that passed the tests locally on my machine. So to me this feature of pijul is clearly an anti-feature, a bug, and the git behavior is correct.
      • baq 3y ago
        You’re describing CI, not git nor pijul, nor any other version control system.
      • 3y ago
• shane_kerns 3y ago
  I believe that even git would work in this scenario because a.txt and b.txt are separate and independent thus a rebase in git is not required. The point at which this becomes an issue is when both person A and B try to make changes to the same file and specifically the same blob of text within that file. I could be wrong but this should be simple enough to prove out because I've run into this situation before where I forgot to rebase before pushing my changes but git still accepted the changes as they were independent of the changes that person B made.
  • CuriousCosmic 3y ago
    git wouldn't accept a push with conflicting changes on the remote but that's just because pushes are dumb (not bad, they just don't do anything fancy). The solution would be to pull upstream changes (so you know what you are potentially pushing your changes into) and then push.
  • Arelius 3y ago
    > thus a rebase in git is not required. A rebase is never required in Git. (people/maintainers may disagre) but a merge will always do. Having said that. In your scenario provided, a pull + merge/rebase will be required. It will then resolve automatically, and without conflicts. But a human has to be involved to provide a strict sequence/dag of the those commits.
• rkangel 3y ago
  Thank you for answering. For me "not needing to pull before pushing" is nice, but not game changing (but helpful to understand nonetheless). It's more the cases that you allude to that we instinctively avoid in git!
  • lillecarl 3y ago
    You say that, but this applies to all cherry picking you can do between branches as well. As long as they don't conflict you're golden, and if there's a conflict you can commit a resolution that'll commute with your branch until you merge back into main. It would enable so many nice and less strict workflows to actually work if it ever got momentum, I've still got hope.
  • adastra22 3y ago
    You've never maintained a long-lived git feature branch, it seems :) I maintain a project that is a slight modification of a very active upstream repo. The changes I maintain are rather invasive. Almost every upstream commit introduces a merge conflict with my changes. To keep myself sane I only merge/rebase when upstream releases a new version, but it still ends up sucking up a few weeks of my time every year. During those weeks, I look enviously at pijul where the conflicts would resolve down to a handful of corrections in context at the point of divergence, instead of gigantic merge conflicts obscured by thousands of piled on patches.
• huimang 3y ago
  This is not really compelling. Pulling and rebasing before a push is standard workflow and lets you test with the new changes before pushing.
  • WolfeReader 3y ago
    That may be standard in some shops, but definitely not all. I view anything that interferes with a push as a threat to the VCS, since it encourages developers to keep changes local and unavailable to their teammates. The only exception would be direct pushes to main.
    • huimang 3y ago
      That doesn't interfere with a push, you're just expecting to blindly push without considering the state of the repo.
• dooglius 3y ago
  The git behavior seems greatly preferable here. As mentioned in other threads, the notion of commutativity here is very weak and counterintuitive; it only seems to cover the applicability of an auto-merge heuristic, not any actual notion of correctness or semantics, so a human is needed to review the merge and re-test before anything can be known safe for pushing upstream. If anything, git is too lenient in allowing auto-merges to take place that could in principle change semantics, and it ought to enforce a manual review stage for any merge, regardless of whether the auto-merge heuristic succeeded or not.
  • exDM69 3y ago
    When the contents has a conflict, git and pijul behave similarly. When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. Pijul will not. As you say, neither will automatically check for correctness and you should run tests and CI when merging. Pijul just removes the manual work when there is no conflict in the contents but the history is different.
    • pmeunier 3y ago
      > When the contents has a conflict, git and pijul behave similarly. Not really: Pijul can record a conflict resolution as a patch, and apply it in a different context. Also, the conflict doesn't "come back", so you don't need extra hacks like rerere/jujutsu. > Pijul just removes the manual work when there is no conflict in the contents but the history is different. This is true, but could be confusing as our definition of conflicts isn't based on contents, but on operations, which is very different from Git (Git doesn't detect all conflicts).
    • jnxx 3y ago
      > When the contents are identical, but the order of commits is different, git will conflict and require manual resolution. But why would this normally happen? Different developers working on the same files which by chance make the same changes? Isn't that unlikely?
  • pmeunier 3y ago
• crabbone 3y ago
  Merges are bad only when all parties involved edited the same code. There's no programmatic way to solve this problem. It's an administrative problem: someone has to decide whose code is the right one to use. If changes coming from both sources are independent, then rebase in Git is trivial as well, and there's nothing to be afraid of.
  • jnxx 3y ago
    > It's an administrative problem: someone has to decide whose code is the right one to use. Or maybe an architectural one.
• jnxx 3y ago
  > 1) git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. But is this not the right thing to do? A kernel is a complex piece of software. Changes in one place can have very non-obvious consequences in other places (think of changes that cause deadlock because locks are applied in the wrong order). Of course, it is theoretically nice if I know that a change to e.g. documentation or fixing a typo in a comment is not affecting the Ethernet driver or the virtual file system layer, but this is down to the architecture of the project - this is not something that a version control system can prove. Given that, it seems desirable to me that the source tree has as few different variations, permutations how to get there, and so on, as possible, since this makes testing and things like bisecting for something like a broken lock or another invariant much easier.