3 ms·

> That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 1. Sorry, I get that you mi

> That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 1. Sorry, I get that you might be angry at Pijul for some reason, but this is simply not true. The lack of associativity of 3-way merge is absolutely not hidden, and gets merges wrong sometimes. But more fundamentally, the fact that commits must be ordered is not an implementation detail, it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository. Conflicts in Pijul are detected correctly, and a conflicting state is another valid state, whereas in Git, a conflict is a failure to merge, and the user must solve the conflict before doing anything else. In particular, this implies that a conflict resolution in Git can be propagated to other repositories only if the two conflicting commits were merged at the exact same time in all repositories. 2. Working on parts of the repository in Git only works for checkout, you still have to clone the entire repository, and Git still has the entire repo, even it is not shown to the user in its entirety. This completely defeats the point of partial clones, and prevents, in many cases, the use of Git on monorepos. That said, I'm not sure why this is the case, Git could very well produce a commit using a tree whose blobs are not all downloaded, just like when you commit from a shallow clone. But even if this worked, Git requires you to send the entire history of the full repository if you want to clone it to a remote machine, whereas Pijul lets you select the patches relative to just a part of the repository. This is because in Pijul, patches commute! If you place your patches in a sequence, you can reorder the patches you want to send (without changing their identifier) to be the first ones in the sequence, and then send just a prefix of the sequence. All this without any extra operation, rebase or anything else.

arghwhat 8y ago
What I dislike about Pijul is that it entirely fails to sell itself. Pijul is a product that seeks adoption. I'm a customer. Pitch. Pijul fails to present me any reason or example for its superiority to the status quo, Git. It only provides vague points like simply claiming to be more "correct". I need to know how my workflow will improve as a result of replacing Git with Pijul. Sure, you might say that I'm not the target, but as a software developer running my own DevOps product and consultancy company, I don't find that to be the case. For your specific counter-arguments: 1. Pointing out a corner-case pain point with Git, and simply stating that Pijul will be "correct" is not at all informative. Git has countless pain points, and so will Pijul have. What matters is the 90% experience, not the corner cases. "A conflicting state is another valid state" does not mean anything to a user. The source is not in a valid state during conflict, and sharing invalid source is not interesting, so this falls under implementation details again. Merges have pros and cons, which is why Git also has other mechanisms which the users can select, such as rebase. Again, what one needs to know is how the workflow of a developer is affected, not how beautiful the internal structures may end up being. 2. Ah, a partial checkout and a partial clone differ, at least in Git terminology, which is the status quo at the current time. However, what people care about is not the ability to perform a partial clone, but the speed of certain operations. If a full clone is fast, the user won't give a damn about partial clones. Instead, what one should then put as a prominent feature is monorepo capability, and direct performance comparisons between Git and Pijul. However, do note that Microsoft appears to handle monorepos in Git just fine with GVFS, through partial clones. Also, the ability to reorder patches without changing their identifier will to many be an anti-feature which might render Pijul a no-go. From a user-perspective, Pijul and Git are both equally capable of reordering patches, Pijul just lacks the ability to easily and uniquely identify an entire tree state.
- pmeunier 8y ago
  You seem to be faster at writing than at reading, I already answered your point 1: > it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository. Any team with enough people, or working at a fast enough pace, knows this doesn't work in Git. Pijul completely solves it by thinking in an entirely different way (changes instead of snapshots). This is not an implementation detail at all, the two mental models are extremely different. About your point 2, what can I say? You picked the example, and now that you're not liking it anymore, you are trying to blame it on me? I don't find that fair.

arghwhat 8y ago

What I dislike about Pijul is that it entirely fails to sell itself. Pijul is a product that seeks adoption. I'm a customer. Pitch. Pijul fails to present me any reason or example for its superiority to the status quo, Git. It only provides vague points like simply claiming to be more "correct". I need to know how my workflow will improve as a result of replacing Git with Pijul. Sure, you might say that I'm not the target, but as a software developer running my own DevOps product and consultancy company, I don't find that to be the case. For your specific counter-arguments: 1. Pointing out a corner-case pain point with Git, and simply stating that Pijul will be "correct" is not at all informative. Git has countless pain points, and so will Pijul have. What matters is the 90% experience, not the corner cases. "A conflicting state is another valid state" does not mean anything to a user. The source is not in a valid state during conflict, and sharing invalid source is not interesting, so this falls under implementation details again. Merges have pros and cons, which is why Git also has other mechanisms which the users can select, such as rebase. Again, what one needs to know is how the workflow of a developer is affected, not how beautiful the internal structures may end up being. 2. Ah, a partial checkout and a partial clone differ, at least in Git terminology, which is the status quo at the current time. However, what people care about is not the ability to perform a partial clone, but the speed of certain operations. If a full clone is fast, the user won't give a damn about partial clones. Instead, what one should then put as a prominent feature is monorepo capability, and direct performance comparisons between Git and Pijul. However, do note that Microsoft appears to handle monorepos in Git just fine with GVFS, through partial clones. Also, the ability to reorder patches without changing their identifier will to many be an anti-feature which might render Pijul a no-go. From a user-perspective, Pijul and Git are both equally capable of reordering patches, Pijul just lacks the ability to easily and uniquely identify an entire tree state.

pmeunier 8y ago
You seem to be faster at writing than at reading, I already answered your point 1: > it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo" a merge, and push that undoing to a remote repository. Any team with enough people, or working at a fast enough pace, knows this doesn't work in Git. Pijul completely solves it by thinking in an entirely different way (changes instead of snapshots). This is not an implementation detail at all, the two mental models are extremely different. About your point 2, what can I say? You picked the example, and now that you're not liking it anymore, you are trying to blame it on me? I don't find that fair.