Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pijul – A free and open source distributed version control system

pijul.org

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Pijul – A free and open source distributed version control system

#61

Post by yaseer »

mhd wrote: post #26

"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.

I think they're implying that the mathematical model creates a pattern of behaviour in the software that's intuitive.

For vim users, that's how vim keybindings work, for example (not everyone would agree vim is intuitive, hence I qualified the user-base). If you learn vim's keybindings, they're like axioms. You start to intuit the patterns like you would a language, eventually you don't think about how to do something, your fingers intuitively know.

Re: Pijul – A free and open source distributed version control system

#62

Post by lvh »

krupan wrote: post #54
lvh wrote: post #35

Earlier 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 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…

darcs and pijul have an internal model that tells it where patches can go; it does not suggest patches can go pretty much everywhere (in fact; at any given time it probably only has exactly one idea of which order the patches go in). Once those patches have dependencies, it enforces their order; but e.g. groups of dependent patches can still be transplanted around.

The Darcs wiki has some cool graphics around cherry-picking merges that might answer your question better than a paragraph of prose can: http://darcs.net/Using/Model#merging-with-cherry-picking

Re: Pijul – A free and open source distributed version control system

#64

Post by lvh »

gpm wrote: post #50
lvh wrote: post #40

Earlier quoted context omitted.

Define "your code which you put in a repository"? Disclaimer: IANAL. AGPL enforcement is generally a little unclear. If you ship a binary, you have to make the source available. If your binary answers on the wire but you don't ship it you (under the APL) have to make the source available. So, uh, yes -- as long as you never use it, which seems a little silly of a definition?

> Define "your code which you put in a repository"? ... Code you add with the equivalent of `git add; git commit`. I.e. suppose git was AGPL instead of GPL, that would have no effect on the license of say, Rust (MIT+Apache) regardless of the fact that git is used in the development.

My apologies, I completely misunderstood your question.

Again, (A)GPL enforcement is unclear and subject of real debate, but my understanding is that nobody thinks virality impacts data being used by the program (e.g. source code in a VCS).

Re: Pijul – A free and open source distributed version control system

#66

Post by cstrahan »

OJFord wrote: post #58
cstrahan wrote: post #37

Earlier quoted context omitted.

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.

Of course non-commutative can be a part of a mathematical model; no, I'm not showing the opposite point.

For clarification, my point is this: if some operation can be proven to be commutative, but you don't acknowledge that it is, you've just made things more difficult for yourself (and maybe others). It would be absurd if someone worked really hard to evaluate a_1+a_2+...a_n strictly left to right, when there might a more convenient (from a human grey-matter standpoint) order to evaluate those numbers. That's because we know that addition here is associative and commutative. Uncovering these properties is what math is all about -- discovering these truths and exploiting them to good effect.

If you can prove that something is not commutative given your axioms, you can attempt to revise your axioms -- maybe one axiom was redundant and only served to impose unnecessary constraints on your model. If you can't find a revised set of axioms that satisfy what you need, congrats -- you've found the simplest system you could come up with -- though someone might, down the road, come along and show you that there was, indeed, a simpler set of axioms that you couldn't envision. That's the process of mathematical development.

If you're good at math, you'll discover the axioms you need to get the generality you're looking for, and if commutativity is to be had, you'll find a way to get it. If you find no way to get you some commutativity, you at least avoid pretending that you have it (that is, you don't write buggy software).

Good math skills will either get you commutativity (which is intuitive) or prove non-commutativity (intuitive again, because you're avoiding bugs) -- it's win-win.

Re: Pijul – A free and open source distributed version control system

#68

Post by jdbernard »

lvh wrote: post #53
jdbernard wrote: post #38

Earlier 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?

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 manual…

So, I didn't believe you because my internal mental model of a git repo is a DAG of changesets. And indeed, that is a good way to think about it, because almost all of git's operations behave like this. Commit history is almost always presented to the user as a series of diffs.

But, you are correct. Internally, git stores the full contents of files and computes the diffs on the fly.

For others' benefit, if you want to test for yourself, create a new repo, add a file and make a series of commits with changes. Git objects are compressed with DEFLATE (zlib) so gunzip and unzip won't work. I used https://github.com/jezell/zlibber because I was too lazy to write my own quick zlib wrapper. Then doing

    for o in .git/objects/*/*; do cat "$o" | inflate ; echo ""; done
lists the contents of all the git objects. Notice that there are no changesets, only full copies of the file you modified at different states.

This was surprising to me, since I had a very different model mentally. I still think the DAG of diffs is the better model mentally, but it is worth understanding that this is not what git is actually doing under the hood. It explains issues that arise doing rebases, cherry-picks, etc.

I now also understand the motivation behind Pijul. If I understand correctly, Pijul does use a collection of changesets as the underlying model. Like you say, that can be a critical difference.

Re: Pijul – A free and open source distributed version control system

#69

Post by jordigh »

krupan wrote: post #54
lvh wrote: post #35

Earlier 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 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…

A commit is not a patch. A commit is just often represented as a patch (i.e. a diff), but in general neither git nor hg even save a commit as a patch, except as a minor, optional, and opaque optimisation. What they really save is the entire state of your repo at a particular time, with the hash(es) of the state of the repo just before this one. In the case of git, it saves a tree of hashes that refer to all of the blobs (files) at the current commit. In the case of Mercurial, it saves a manifest of hashes that point to files represented in revlogs. Whenever both git and hg show you a commit as a diff, this involves a computation. They are not merely showing you diffs that they have pre-computed and stored.

Bitkeeper does have a weave data structure that more closely resembles patches. It's an encoded set of instructions for transforming one file from one state into another:

https://www.bitkeeper.org/src-notes/SCCSWEAVE.html

This data structure has a big advantage when computing annotations (blames): it's much faster than Mercurial's revlog (which in turn is faster than git's blob-tree-ref structure).

Re: Pijul – A free and open source distributed version control system

#70

Post by cstrahan »

OJFord wrote: post #58
cstrahan wrote: post #37

Earlier quoted context omitted.

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.

A simpler explanation to that of my sibling post -- your point is akin to this fallacy:

Susan: My brother plays such great music with his violin!

Bob: Actually, I think you're arguing the opposite point -- a violin has strings that can be mishandled such that they cause annoying screechy sounds, so surely he's capable of producing a cacophony of screechy sounds. Not so enjoyable.

Susan: Okay... but he's a good musician, so though he could fuck up a performance if he wanted to, he doesn't -- he plays to the best of his abilities.

If a math model claims that something isn't commutative, it's either as simple/general as it can be, or the creators of that model are bad at math (they left commutativity on the table due to bad axioms, or their theorem that the given operation was not commutative was wrong).

Post reply on HN