"Because Pijul is based on a mathematical model of collaborative edition, its behavior matches intution, every time." That's not how math and/or intuition works.
What is "collaborative edition"? Does it mean the same thing as collaborative editing?
Pijul – A free and open source distributed version control system
51–60 of 180 posts
Re: Pijul – A free and open source distributed version control system
#52Earlier quoted context omitted.
Git stores diffs, not snapshots. A commit is a changeset, literally a patch that you can export with `git diff`. Ordering of is layered on top of that and informs things like merges. Can you explain a little more what you mean?
Git does store snapshots, not diffs. Look into the files in .git/objects/* ;)
[deleted]
Re: Pijul – A free and open source distributed version control system
#53Earlier quoted context omitted.
Git (and mercurial, and a few others) are snapshot-based. That means that they think of the world as states, with changes between them. Darcs, and pijul, are patch-based. That means that they think of the world as an ordering of patches. Patches aren't the same as commits: commit orderings, for example, are fixed, whereas patch orderings are computed. They can change when you e..g merge a "branch". Branching is simil…
Git stores diffs, not snapshots. A commit is a changeset, literally a patch that you can export with `git diff`. Ordering of is layered on top of that and informs things like merges. Can you explain a little more what you mean?
Internally, git objects are snapshots -- the differences are computed on demand. That is a critical difference, because it has implications for how merging can work. For example: https://tahoe-lafs.org/~zooko/badmerge/simple.html
Even when using git am or send-email or whatever, yes, you're sending a patch -- but the way to apply that patch is to turn it into a commit and then cherry pick or rebase or merge or manually fix conflicts or whatever. In darcs and pijul, the model is _always_ that set of patches.
Re: Pijul – A free and open source distributed version control system
#54How does this compare to git?
Git (and mercurial, and a few others) are snapshot-based. That means that they think of the world as states, with changes between them. Darcs, and pijul, are patch-based. That means that they think of the world as an ordering of patches. Patches aren't the same as commits: commit orderings, for example, are fixed, whereas patch orderings are computed. They can change when you e..g merge a "branch". Branching is simil…
This distinction between commits and patches (I've been following git, hg, and darcs for over a decade) is one I've never quite understood. A patch says, take this original line of code found here and change it into this new line of code. A commit is just a patch that records when in the history you can be sure to find that original line of code. If you take an arbitrary patch and apply it to an arbitrary set of code you might not even be able to find that original line of code. How do darcs and/or pijul solve that problem? Git and mercurial have tools like rebase and cherry pick that allow you to rearrange commits and they can even use three way merge algorithms (because of the DAG) to help recompute the patches for when that original line of code isn't quite what the patch specifies anymore. How are darcs and/or pijul different in that regard?
Re: Pijul – A free and open source distributed version control system
#55How does this compare to git?
I guess, you will see a lot more parallel branches with Pijul compared to git.
Assume you change file A, commit, then change file B, and commit. In git there is a dependency from the second to the first commit, because the state of the second is derived from the first one. However, the changes are unrelated because they are in different files. Pijul understands them as parallel unrelated changes (although with different time stamps).
(disclaimer: I infer that from using darcs many years ago. I never used Pijul)
Re: Pijul – A free and open source distributed version control system
#56Earlier quoted context omitted.
This doesn't seem significantly different to git, from the perspective of a user. Under the hood, I model a git branch as a ref pointing to a commit object in a DAG. In the driver's seat (git log --patch branch..upstream), I think of it as an ordered collection of diffs.
It is different. When you commit in darcs, you cherry pick as default.
I don't understand, you will have to use more words. I've never used darcs, and as a git user I don't see how you could cherry-pick by default for commiting. By default, I would say you… create a commit object with the author/date/message/tree/parent metadata recorded in it.
Re: Pijul – A free and open source distributed version control system
#57Earlier quoted context omitted.
Since when does anybody ever check the license of compiled binary applications?
If you buy a macOS machine today, it ships with bash3.2 by default. That's the last version that was GPLv2. It is a decade old by now. Some companies most definitely care.
Yes, you are right companies care, but they aren't good companies.
Re: Pijul – A free and open source distributed version control system
#58"Because Pijul is based on a mathematical model of collaborative edition, its behavior matches intution, every time." That's not how math and/or intuition works.
Math itself isn't necessarily intuitive in every case, but I think their point is this: if their system follows the simplest (i.e. most general) mathematical model, things will be more intuitive (i.e. more special cases == more difficult to reason about). Let's look at example from math: integers and addition. Addition is pretty general -- there aren't, say, weird special cases when one operand is even, or the curren…
I think you showed the opposite point - you've argued commutativity is intuitive, but certainly non-commutativity can be part of a mathematical model.
Re: Pijul – A free and open source distributed version control system
#59Earlier quoted context omitted.
Git stores diffs, not snapshots. A commit is a changeset, literally a patch that you can export with `git diff`. Ordering of is layered on top of that and informs things like merges. Can you explain a little more what you mean?
Not sure why you're getting downvoted, you're describing git correctly. If anyone is questioning this, just play with `git rebase -i [some old changeset id]` and you'll see that it's just an ordering of patches.
git rebase -i does not demonstrate that gits internal model involves a DAG of snapshots (objects); it only demonstrates that git is sometimes willing to move the contents of one of those snapshots around to create a new snapshot. That is very different from a patches-always model, as I have illustrated in a sibling comment with an example link.
Re: Pijul – A free and open source distributed version control system
#60Earlier quoted context omitted.
Git (and mercurial, and a few others) are snapshot-based. That means that they think of the world as states, with changes between them. Darcs, and pijul, are patch-based. That means that they think of the world as an ordering of patches. Patches aren't the same as commits: commit orderings, for example, are fixed, whereas patch orderings are computed. They can change when you e..g merge a "branch". Branching is simil…
This doesn't seem significantly different to git, from the perspective of a user. Under the hood, I model a git branch as a ref pointing to a commit object in a DAG. In the driver's seat (git log --patch branch..upstream), I think of it as an ordered collection of diffs.
In darcs or pijul there is no DAG; there is only a collection of patches. The ordering between them is implicit, computed on demand, and can change as a consequence of merges.