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

41–50 of 180 posts

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

#41

Post by falsedan »

lvh wrote: post #35
gozzoo wrote: post #27

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

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

#42

Post by kibwen »

fadzlan wrote: post #33
3825 wrote: post #14

Earlier quoted context omitted.

Any sources behind the claim that agpl is behind the lack of success for rethinkdb? I am very bullish about agpl. As far as I understand, the choice of agpl has no effect on your code which you put in a repository. Is that not the case?

Honest question, although on a bit different topic I guess. Does AGPL prevents some company creating Github like services for Pijul?

It does not prevent any company from creating a Pijulhub. However, if you make modifications to Pijul or link it as a library into other code, that code must be made open-source.

(And note that GitHub doesn't even use the original git written by Linus, they wrote their own implementation, libgit2.)

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

#43

Post by qznc »

jdbernard wrote: post #38
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…

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/* ;)

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

#44

Post by mempko »

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.

If you want to be good at math, you MUST gain an intuitive understanding of it.

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

#45

Post by lvh »

fadzlan wrote: post #33
3825 wrote: post #14

Earlier quoted context omitted.

Any sources behind the claim that agpl is behind the lack of success for rethinkdb? I am very bullish about agpl. As far as I understand, the choice of agpl has no effect on your code which you put in a repository. Is that not the case?

Honest question, although on a bit different topic I guess. Does AGPL prevents some company creating Github like services for Pijul?

There is serious disagreement between serious legal scholars (Moglen, Rosen) about what kind of cooperation between components would trigger (A)GPL virality clauses. Linking counts according to one, but not the other; IIUC everyone agrees subprocesses don't count.

So, assuming said company would not want to AGPL their code (and assuming they don't distribute binaries), that choice would imply some technical decisions they would presumably not be very happy about, but overall: no.

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

#46

Post by mempko »

falsedan wrote: post #41
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 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.

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

#47

Post by Avshalom »

fadzlan wrote: post #33
3825 wrote: post #14

Earlier quoted context omitted.

Any sources behind the claim that agpl is behind the lack of success for rethinkdb? I am very bullish about agpl. As far as I understand, the choice of agpl has no effect on your code which you put in a repository. Is that not the case?

Honest question, although on a bit different topic I guess. Does AGPL prevents some company creating Github like services for Pijul?

Not really it just means the ticket tracking/wiki/etc... features can't get so cozy with pijul that they become 'derivative works'.

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

#48

Post by tghw »

jdbernard wrote: post #38
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…

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.

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

#49

Post by falsedan »

lliamander wrote: post #34
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.

Indeed, but if can accurately deduce what the behavior will be from a few relatively simple rules, then that is an excellent basis for forming an intuition.

That's a deduction… intuition is usually drawing conclusions based on pattern-matching on similar situations (e.g. 'how do I do this in git/svn?').

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

#50

Post by gpm »

lvh wrote: post #40
3825 wrote: post #14

Earlier quoted context omitted.

Any sources behind the claim that agpl is behind the lack of success for rethinkdb? I am very bullish about agpl. As far as I understand, the choice of agpl has no effect on your code which you put in a repository. Is that not the case?

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.

Post reply on HN