5 ms·

I have visited the pijul site 2 or three times, every time I would start reading about a "sound mathematical theory", get bored, and close the tab. To this date

I have visited the pijul site 2 or three times, every time I would start reading about a "sound mathematical theory", get bored, and close the tab. To this date I still don't know what pijul is trying to do and why I should be interested on it. They really should improve their documentation (hint, in case someone reads this: nobody except a few geeks give a shit about sound mathematical models. Show me how pijul makes my life easier compared to git, that's all I need)

avodonosov 6y ago
Have you ever rebased a long chain of git commits onto new branch, where one of the first of those commits have a conflict with the new base, and after resolving this conflict for that commit you have the same conflict over and over again for all the subsequent commits, even if they did not modify that place in the code, and you need to manually resolve it again and again? Pijul will, as I understand, save us from those unnecesary repeated "conflicts". See also the answer by @chriswarbo about removing unndesired changes from history
- jayd16 6y ago
  Could one not add a new rebasing strategy to git by generating patches from the git history? Are the concepts non-translatable?
  - avodonosov 6y ago
    I think rebase alreaby works by generating patches, but for some reason the repeated conflicts happen...
- zemo 6y ago
  you know about rerere right? https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere
  - MattIPv4 6y ago
    I feel like this is missing something about the drawbacks? Or are there truly no drawbacks beyond disk usage for the cache, and folks should just enable it once they're aware it exists?
    - mekkkkkk 6y ago
      I guess it involves a bit of assumptions and guesswork to automatically replay your previous actions to files that in turn may have changed. It probably slightly increases the chances of Git doing something you didn't expect, and not tell you about it. Hence why it isn't default. Maybe?
  - avodonosov 6y ago
    No, I did hot know that, repeated everything manually. Will try that next time, thank you. BTW, pijul docs mention rerere as helping "in some cases": > This is why in these systems, conflicts are often painful, as there is no real way to solve a conflict once and for all (for example, Git has the rerere command to try and simulate that in some cases). https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html
    - bombcar 6y ago
      I feel their example (with the ABGX) just makes me think "merging can result in weirdness silently and git and pijul do it different but silent" - it doesn't really argue that one is better than the other. (Most people probably use git as an effectively infinite string of zip files anyway. https://xkcd.com/1597/ https://xkcd.com/1597/ )
      - pmeunier 6y ago
        To the contrary, that example actually gives a solid argument for three points where Pijul is better than Git: 1. The order between lines is preserved by Pijul. This is important: let's say Alice works at the beginning of the file (lines 1-10 of 1000), whereas Bob works at the end (lines 990-1000 of 1000). Pijul preserves the order in all cases, whereas Git might randomly decide, based on the contents of the lines, to merge Bob's new lines in the middle of Alice's new lines. 2. Git solves an optimisation problem (3-way merge) that may have multiple solutions. Unfortunately, there is no way to count the number of solutions, or even to tell whether there are multiple solutions, in a reasonable amount of time. Git therefore picks one solution silently, based on the contents of the lines. In contrast to that, Pijul is deterministic. 3. Pijul is associative, meaning that merging A and (BC) is the same as first merging A and B, and then merging C; in other words, you can merge a branch commit by commit. Git doesn't have that property: if you merge a branch, you MUST (1) stop working on it, or else the future merges become totally unpredictable, and artificial conflicts might come back (yes, I know about dirty-hacks-to-try-and-fix-that-when-they-work such as rerere), and (2) check the result of the merge extremely carefully, because in addition to the logical errors that merges can reasonably introduce, Git might also introduce extra unpredictable errors by randomly shuffling lines around.
pmeunier 6y ago
There's zero theory on the following page: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html There are many answers: 1. Commutation makes your life easier because you can be much less careful about how you manage your branches. Rebase, merge and commit are the same operation (apply a patch), without any loss of power: you can simulate all of Git within Pijul, except for bad (i.e. silent non-associative merges), which Pijul doesn't have. 2. Everything is easily reversible. I know all actions in Git are reversible in some way, but not in the same way: for example, you can't undo an old patch without changing the identity of all the patches after it. I know you're thinking this is important for strong version identifiers, but Pijul also has strong version identifiers, just without the compromise on usability. This is achieved using cool cryptography tricks. 3. Solving a conflict in Pijul actually solves it. Conflicts happen between two (or more) patches, and are solved by a patch: if the same two patches are on another branch, you are guaranteed to get the exact same conflict in 100% of cases, and that conflict is solved by the very same patch that solved it in the first branch. 4. When merging, Git solves an optimisation problem that may have multiple solutions in some cases. Git chooses one arbitrary solution based on the content of the lines, and doesn't warn you if there are others (because that would be a very hard computational problem). Pijul doesn't do that, and gives you strong guarantees on merges. You still have to test, but when reviewing, you can predict in your head, with 100% accuracy, how Pijul will merge. This isn't the case in Git: lines inserted at the end of a file might be merged into unrelated lines at the beginning of a file sometimes, if Git feels like it.

avodonosov 6y ago

Have you ever rebased a long chain of git commits onto new branch, where one of the first of those commits have a conflict with the new base, and after resolving this conflict for that commit you have the same conflict over and over again for all the subsequent commits, even if they did not modify that place in the code, and you need to manually resolve it again and again? Pijul will, as I understand, save us from those unnecesary repeated "conflicts". See also the answer by @chriswarbo about removing unndesired changes from history

jayd16 6y ago
Could one not add a new rebasing strategy to git by generating patches from the git history? Are the concepts non-translatable?
- avodonosov 6y ago
  I think rebase alreaby works by generating patches, but for some reason the repeated conflicts happen...
zemo 6y ago
you know about rerere right? https://www.git-scm.com/book/en/v2/Git-Tools-Rerere https://www.git-scm.com/book/en/v2/Git-Tools-Rerere
- MattIPv4 6y ago
  I feel like this is missing something about the drawbacks? Or are there truly no drawbacks beyond disk usage for the cache, and folks should just enable it once they're aware it exists?
  - mekkkkkk 6y ago
    I guess it involves a bit of assumptions and guesswork to automatically replay your previous actions to files that in turn may have changed. It probably slightly increases the chances of Git doing something you didn't expect, and not tell you about it. Hence why it isn't default. Maybe?
- avodonosov 6y ago
  No, I did hot know that, repeated everything manually. Will try that next time, thank you. BTW, pijul docs mention rerere as helping "in some cases": > This is why in these systems, conflicts are often painful, as there is no real way to solve a conflict once and for all (for example, Git has the rerere command to try and simulate that in some cases). https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html
  - bombcar 6y ago
    I feel their example (with the ABGX) just makes me think "merging can result in weirdness silently and git and pijul do it different but silent" - it doesn't really argue that one is better than the other. (Most people probably use git as an effectively infinite string of zip files anyway. https://xkcd.com/1597/ https://xkcd.com/1597/ )
    - pmeunier 6y ago
      To the contrary, that example actually gives a solid argument for three points where Pijul is better than Git: 1. The order between lines is preserved by Pijul. This is important: let's say Alice works at the beginning of the file (lines 1-10 of 1000), whereas Bob works at the end (lines 990-1000 of 1000). Pijul preserves the order in all cases, whereas Git might randomly decide, based on the contents of the lines, to merge Bob's new lines in the middle of Alice's new lines. 2. Git solves an optimisation problem (3-way merge) that may have multiple solutions. Unfortunately, there is no way to count the number of solutions, or even to tell whether there are multiple solutions, in a reasonable amount of time. Git therefore picks one solution silently, based on the contents of the lines. In contrast to that, Pijul is deterministic. 3. Pijul is associative, meaning that merging A and (BC) is the same as first merging A and B, and then merging C; in other words, you can merge a branch commit by commit. Git doesn't have that property: if you merge a branch, you MUST (1) stop working on it, or else the future merges become totally unpredictable, and artificial conflicts might come back (yes, I know about dirty-hacks-to-try-and-fix-that-when-they-work such as rerere), and (2) check the result of the merge extremely carefully, because in addition to the logical errors that merges can reasonably introduce, Git might also introduce extra unpredictable errors by randomly shuffling lines around.

pmeunier 6y ago

There's zero theory on the following page: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html There are many answers: 1. Commutation makes your life easier because you can be much less careful about how you manage your branches. Rebase, merge and commit are the same operation (apply a patch), without any loss of power: you can simulate all of Git within Pijul, except for bad (i.e. silent non-associative merges), which Pijul doesn't have. 2. Everything is easily reversible. I know all actions in Git are reversible in some way, but not in the same way: for example, you can't undo an old patch without changing the identity of all the patches after it. I know you're thinking this is important for strong version identifiers, but Pijul also has strong version identifiers, just without the compromise on usability. This is achieved using cool cryptography tricks. 3. Solving a conflict in Pijul actually solves it. Conflicts happen between two (or more) patches, and are solved by a patch: if the same two patches are on another branch, you are guaranteed to get the exact same conflict in 100% of cases, and that conflict is solved by the very same patch that solved it in the first branch. 4. When merging, Git solves an optimisation problem that may have multiple solutions in some cases. Git chooses one arbitrary solution based on the content of the lines, and doesn't warn you if there are others (because that would be a very hard computational problem). Pijul doesn't do that, and gives you strong guarantees on merges. You still have to test, but when reviewing, you can predict in your head, with 100% accuracy, how Pijul will merge. This isn't the case in Git: lines inserted at the end of a file might be merged into unrelated lines at the beginning of a file sometimes, if Git feels like it.