5 ms·

> If you're doing this [..], you're doing it wrong. [..] This is not 100% true (see my answer to the second part below), but the point of Pijul is that you don

> If you're doing this [..], you're doing it wrong. [..] This is not 100% true (see my answer to the second part below), but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. In the end, a version control system is just a tool, not a way of life or a work methodology. Sure, there are example projects where the Git way is the best, but they are quite rare (one example is Software Heritage [1]). > If you work this way, you can merge the patch cleanly into all target branches, and this new patch becomes the new merge-base. So you can actually continue to apply new patches without any conflicts. This is not actually true, and is the whole point of Pijul. In Git, your suggestion works only as long as (1) there is never any conflict, else you need "git rerere", and (2) 3-way merge never runs into a non-associative merge [2]. [1] https://www.softwareheritage.org/ https://www.softwareheritage.org/ [2] https://tahoe-lafs.org/~zooko/badmerge/simple.html https://tahoe-lafs.org/~zooko/badmerge/simple.html

frutiger 7y ago
> This is not actually true, and is the whole point of Pijul. In Git, your suggestion works only as long as (1) there is never any conflict, else you need "git rerere", and (2) 3-way merge never runs into a non-associative merge [2]. Sure, if the two branches have diverged around the location of the patch, there will need to be a merge resolution. Wouldn’t Pijul require the same too?
- pmeunier 7y ago
  First, even though Pijul has branches, patch commutation means that most Git branches are just regular patches in Pijul. > Wouldn’t Pijul require the same too? If you're talking about my point (1) above, the answer to your question is no, because in Pijul, conflicts are resolved by patches, so if a branch has a patch solving a conflict, the conflict cannot come back. So Pijul doesn't need "rerere". If you're talking about my point (2), the answer is also no: non-associative merges happen for bad reasons in Git. By design, Pijul doesn't have them at all.
  - frutiger 7y ago
    > If you're talking about my point (1) above, the answer to your question is no, because in Pijul, conflicts are resolved by patches, so if a branch has a patch solving a conflict, the conflict cannot come back. So Pijul doesn't need "rerere". No, that’s not what I was asking. Conflicts don’t come back in git either, if you base the change off the merge-base. As I said, if the area around the patch has diverged between the release and development branches, you will need to manually resolve the conflict as you merge from the patch branch (based off the merge-base). That’s nothing to do with git, these tools do not have semantic understanding of your business problem so obviously require human input. My question was, in that case wouldn’t Pujil need assistance too? Your reply: “conflicts are resolved by patches” - indicates there was a conflict that needed to be resolved by a human or not?
    - pmeunier 7y ago
      > My question was, in that case wouldn’t Pujil need assistance too? > Your reply: “conflicts are resolved by patches” - indicates there was a conflict that needed to be resolved by a human or not? Yes, conflicts need to be resolved by humans indeed (sorry for misunderstanding your question).
codetrotter 7y ago
Regarding that second link about the bad merge, I think there is a deeper problem at hand. Namely that we still work with the textual representation of a program as the “source of truth”, but each time we save and commit this way, a lot of information is lost. What I would like is instead of representing source code as text to have a binary representation of the AST of the software that I am writing where, crucially, all edit operations are recorded into history. Perhaps such a binary format could even be slightly faster to work with in terms of time taken for editor and compiler to parse it? And not only record edit operations, but differentiate between instancing and copying a node, so that we can express whether code that we duplicate should be edited everywhere automatically in the codebase when we change it, or if they should be allowed to diverge. (Both of which make sense in different contexts and would be great to actually express in the source representation and have the IDE read and understand.) Furthermore, such a representation could allow for more freedom when positioning elements of the code because we aren’t constrained to just lines and lines of text with characters next to each other and lines above and below each other. Now, a lot of non-textual editors exist already but I haven’t seen any that I like and besides I don’t want another language, I want to write Rust code in such a way as outlined here.
- the_duke 7y ago
  This seems to be exactly what the Unison language [1] tries to do. I actually have been thinking about how the concept could be implemented for Rust. [1] https://news.ycombinator.com/item?id=22009912 https://news.ycombinator.com/item?id=22009912
rumanator 7y ago
> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. At best, the argument made by Pijul's backers is that Pijul implements this feature differently and in a way that arguably may be creating a problem where in Git there is none.
- pmeunier 7y ago
  > The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.
  - rumanator 7y ago
    There is a clear argument that you chose to ignore: cherry-picks are patently not a problem in Git, and the only problematic aspect is how some git users might create their own personal problems by developing misinformed workflows while ignoring any information on best practices. If you try to reinvent the wheel on your own, ignore any advice or info, and end up with a badly shaped polygonal thing then you simply can't pin the blame on your chisel.
    - afiori 7y ago
      A lot of the criticism git receive is about the stance that there is the git way and the wrong way. We all are super sure that git has extremely efficient workflows available; it is just that maybe many people do not like them. Git does not try to be a tool for everyone; it is very opinionated on how to best use it; this obviously leaves space for less opinionated tools or even differently opinionated tools to shine under specific use cases/scenario
- dilap 7y ago
  Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev <-> release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.

frutiger 7y ago

> This is not actually true, and is the whole point of Pijul. In Git, your suggestion works only as long as (1) there is never any conflict, else you need "git rerere", and (2) 3-way merge never runs into a non-associative merge [2]. Sure, if the two branches have diverged around the location of the patch, there will need to be a merge resolution. Wouldn’t Pijul require the same too?

pmeunier 7y ago
First, even though Pijul has branches, patch commutation means that most Git branches are just regular patches in Pijul. > Wouldn’t Pijul require the same too? If you're talking about my point (1) above, the answer to your question is no, because in Pijul, conflicts are resolved by patches, so if a branch has a patch solving a conflict, the conflict cannot come back. So Pijul doesn't need "rerere". If you're talking about my point (2), the answer is also no: non-associative merges happen for bad reasons in Git. By design, Pijul doesn't have them at all.
- frutiger 7y ago
  > If you're talking about my point (1) above, the answer to your question is no, because in Pijul, conflicts are resolved by patches, so if a branch has a patch solving a conflict, the conflict cannot come back. So Pijul doesn't need "rerere". No, that’s not what I was asking. Conflicts don’t come back in git either, if you base the change off the merge-base. As I said, if the area around the patch has diverged between the release and development branches, you will need to manually resolve the conflict as you merge from the patch branch (based off the merge-base). That’s nothing to do with git, these tools do not have semantic understanding of your business problem so obviously require human input. My question was, in that case wouldn’t Pujil need assistance too? Your reply: “conflicts are resolved by patches” - indicates there was a conflict that needed to be resolved by a human or not?
  - pmeunier 7y ago
    > My question was, in that case wouldn’t Pujil need assistance too? > Your reply: “conflicts are resolved by patches” - indicates there was a conflict that needed to be resolved by a human or not? Yes, conflicts need to be resolved by humans indeed (sorry for misunderstanding your question).

codetrotter 7y ago

Regarding that second link about the bad merge, I think there is a deeper problem at hand. Namely that we still work with the textual representation of a program as the “source of truth”, but each time we save and commit this way, a lot of information is lost. What I would like is instead of representing source code as text to have a binary representation of the AST of the software that I am writing where, crucially, all edit operations are recorded into history. Perhaps such a binary format could even be slightly faster to work with in terms of time taken for editor and compiler to parse it? And not only record edit operations, but differentiate between instancing and copying a node, so that we can express whether code that we duplicate should be edited everywhere automatically in the codebase when we change it, or if they should be allowed to diverge. (Both of which make sense in different contexts and would be great to actually express in the source representation and have the IDE read and understand.) Furthermore, such a representation could allow for more freedom when positioning elements of the code because we aren’t constrained to just lines and lines of text with characters next to each other and lines above and below each other. Now, a lot of non-textual editors exist already but I haven’t seen any that I like and besides I don’t want another language, I want to write Rust code in such a way as outlined here.

the_duke 7y ago
This seems to be exactly what the Unison language [1] tries to do. I actually have been thinking about how the concept could be implemented for Rust. [1] https://news.ycombinator.com/item?id=22009912 https://news.ycombinator.com/item?id=22009912

rumanator 7y ago

> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. At best, the argument made by Pijul's backers is that Pijul implements this feature differently and in a way that arguably may be creating a problem where in Git there is none.

pmeunier 7y ago
> The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.
- rumanator 7y ago
  There is a clear argument that you chose to ignore: cherry-picks are patently not a problem in Git, and the only problematic aspect is how some git users might create their own personal problems by developing misinformed workflows while ignoring any information on best practices. If you try to reinvent the wheel on your own, ignore any advice or info, and end up with a badly shaped polygonal thing then you simply can't pin the blame on your chisel.
  - afiori 7y ago
    A lot of the criticism git receive is about the stance that there is the git way and the wrong way. We all are super sure that git has extremely efficient workflows available; it is just that maybe many people do not like them. Git does not try to be a tool for everyone; it is very opinionated on how to best use it; this obviously leaves space for less opinionated tools or even differently opinionated tools to shine under specific use cases/scenario
dilap 7y ago
Maybe I’m “doing it wrong,” but I have certainly experienced pain cherry-picking fixes and features between dev <-> release branches! Pijul seems to me like it could be a fundamentally better model for VCS, a jump similar to svn -> git.