5 ms·

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

by 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!
  - exDM69 3y ago
    I have clarified the comment above. A pull is needed before pushing. That pull does not need a merge or a rebase like git does because the order of commits A nd B does not matter (iff they are commutative). This gets a lot more useful when there are more than two patches to consider.
  - jnxx 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. A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines. And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.
exDM69 3y ago
You kinda missed the point. You have two repos with different history: master -> patch a -> patch b master -> patch b -> patch a But the contents of the files are equal after applying both patches (in either order). Git will consider these to be two different, Pijul thinks they're the same. This is a simplified example. It only gets interesting when there are a lot of patches, some of which are commutative and some are not.
- ynniv 3y ago
  What benefit is there to the VCS knowing that these histories are equal? That's valuable in verification or efficient binary patching, but I don't see how it matters in version control. When would I want to compare two repositories that were patched in different orders?
  - TOGoS 3y ago
    I'm guessing that it makes it easier to pick and choose between a bunch of patches. This is something I sometimes want to do in Git, but doing so requires a bit of planning. Have all the independent features branch from the same point, then, to 'assemble' them, do an octopus merge. If the VCS knows about dependencies between patches intuitively, it could free me from having to explain it, which in the case of Git, requires following procedures that I'm unlikely to convince any of my coworkers to follow ("ohay, first, decide on the earliest point in the history from which this patch could make sense, rebase onto that....")
  - Arelius 3y ago
    Imagine you are working on a patch heavy project. Like the Linux kernel. Where there are a lot of patchsets going around that are not in the mainline. You and I, who are both working off of main, and who have both separate merged in a few patchsets that are relevant to our shared module of interest. We can merge and compare our branches, and the differences in terms of nursing patches without having to be rigorous about reconciling or histories.

by ynniv 3y ago

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!
- exDM69 3y ago
  I have clarified the comment above. A pull is needed before pushing. That pull does not need a merge or a rebase like git does because the order of commits A nd B does not matter (iff they are commutative). This gets a lot more useful when there are more than two patches to consider.
- jnxx 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. A good example for this is code which grabs several locks and different functions have to do that in the same order, or a deadlock will result. A lot of interaction, even if changes might happen in completely different lines. And I think that's generally true for complex software. Of course it is great if the compiler can prove that there are no data race conditions, but there will always be abstract invariants which have to be met by the changed code. In very complex code, it is essential to be able to do bisecting, and I think that works only if you have a defined linear order of changes in your artefact. Looking at the graphs of changes can only help to understand why some breakage happened, it cannot prevent it.

exDM69 3y ago

You kinda missed the point. You have two repos with different history: master -> patch a -> patch b master -> patch b -> patch a But the contents of the files are equal after applying both patches (in either order). Git will consider these to be two different, Pijul thinks they're the same. This is a simplified example. It only gets interesting when there are a lot of patches, some of which are commutative and some are not.

ynniv 3y ago
What benefit is there to the VCS knowing that these histories are equal? That's valuable in verification or efficient binary patching, but I don't see how it matters in version control. When would I want to compare two repositories that were patched in different orders?
- TOGoS 3y ago
  I'm guessing that it makes it easier to pick and choose between a bunch of patches. This is something I sometimes want to do in Git, but doing so requires a bit of planning. Have all the independent features branch from the same point, then, to 'assemble' them, do an octopus merge. If the VCS knows about dependencies between patches intuitively, it could free me from having to explain it, which in the case of Git, requires following procedures that I'm unlikely to convince any of my coworkers to follow ("ohay, first, decide on the earliest point in the history from which this patch could make sense, rebase onto that....")
- Arelius 3y ago
  Imagine you are working on a patch heavy project. Like the Linux kernel. Where there are a lot of patchsets going around that are not in the mainline. You and I, who are both working off of main, and who have both separate merged in a few patchsets that are relevant to our shared module of interest. We can merge and compare our branches, and the differences in terms of nursing patches without having to be rigorous about reconciling or histories.