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

91–100 of 180 posts

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

#91

Post by lvh »

falsedan wrote: post #56
mempko wrote: post #46

Earlier quoted context omitted.

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.

When you type git pull, it has a remote and a ref at that remote, and it attempts to merge (ff notwithstanding) the DAG you have with the DAG the remote has.

When you type darcs pull, darcs lets you pick and choose which patches (subject to the dependency constraints) you want to pull in. Those patches then get applied however darcs wants to apply them (again, subject to dependency constraints, of cousre). Because you do not necessarily need to pull all of them, you are always "cherry picking" by default.

This is different from cherry-picking in git, because when you cherry-pick in git you still have 2+ commits that exist in the context of a DAG; you're just transplanting the contents elsewhere to create a new commit in a different position in the DAG.

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

#92

Post by [deleted] »

falsedan wrote: post #56
mempko wrote: post #46

Earlier quoted context omitted.

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.

[deleted]

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

#93

Post by [deleted] »

falsedan wrote: post #56
mempko wrote: post #46

Earlier quoted context omitted.

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.

[deleted]

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

#94

Post by jordigh »

halomru wrote: post #88
jordigh wrote: post #69

Earlier quoted context omitted.

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

All that sounds like differences in the intr internal model. From everything I have understood it wor would be possible to reimplement git to store only patches, their position in the commit tree and the commit hash, and have it behave exactly like the git reference implementation. Is the difference between patches and git commits in a DAG really only a difference in internal representations or is there a user-facing…

Speed is about the only user-facing difference. But the big user-facing difference is that commits are glued to their parents. They really are glued; the merges and potential conflicts involved with rebasing and cherry-picking are a consequence of trying to undo this glue.

Darcs' and pijuls' patches aren't glued, they only either commute or do not, and the conflict resolution mechanisms for non-commutative patches are different.

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

#95

Post by lvh »

halomru wrote: post #88
jordigh wrote: post #69

Earlier quoted context omitted.

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

All that sounds like differences in the intr internal model. From everything I have understood it wor would be possible to reimplement git to store only patches, their position in the commit tree and the commit hash, and have it behave exactly like the git reference implementation. Is the difference between patches and git commits in a DAG really only a difference in internal representations or is there a user-facing…

Yes. The DAG in a context in darcs or pijul (so, I have a checkout; how did those files come into existence) is a consequence of the set of patches; the order is computed, not intrinsically part of every commit. This has many UX consequences; for example, when you darcs pull, you automatically cherry-pick patches in any order (as long as you have the dependencies) -- when you git pull, you pull in a commit in a position in a DAG, and automatically merge its entire history.

If you've heard someone say "never git pull, always git fetch and then either merge or rebase as appropriate", then they've noticed the difference between the two.

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

#96

Post by lvh »

dahart wrote: post #84
jdbernard wrote: post #68

Earlier quoted context omitted.

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

I thought git stored diffs too. But I don't understand what difference it makes, isn't the commit storage format an implementation detail? If you want to get to B from A, then I can store B or store B-A. When I have B and want to show a diff, I can calculate B-A. When I have B-A and want to show a diff, it's a no-op. When I have B and want to work, it's a no-op, but when I have B-A and want to work, I have to populat…

The difference is more than just the storage format. You could compute snapshots on demand and just store the diffs (that'd be impossibly slow, but you could), but you still would have git's DAG instead of darcs' theory of patches, with all of the consequences of that. (I'd explain them here, but I've already explained it in sibling comments on this thread).

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

#97

Post by WorldMaker »

falsedan wrote: post #71
lvh wrote: post #60

Earlier quoted context omitted.

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.

It sounds as this is mostly an internal difference. Certainly, the mental model you described can be used on git reasonably well, from the user's point of view, and they won't get steered too far off course with it.

It can be used in git, with a lot of duct tape like git rebase and git cherry-pick and occasional dynamiting through rough git merges.

The darcs/pijul world of repositories as loose ordered sets of patches makes cherry-picking the rule rather than the exception. A branch is mostly just the subset of patches you are interested in at a given moment. A "trunk" is just the superset of all possible patches. You can make interesting and easy usages of things like set intersections [1]: the intersection of the patches in two branches in darcs/pijul can be much more interesting than nearest common parent commit in the git DAG, and especially can be a lot more informative in the cases where things like bug fixes are cherry-picked across branches, which in git is a special bit of tree/commit surgery but in the darcs/pijul world that patch can be often the exact "same" in both branches.

[1] Aside, I love the concept of using intersection branches for consensus-oriented development (what releases to Production are the patches that every developer has pulled into their own working branch), which is a neat form of decentralized development that I think can only really be handled in the darcs/pijul model. (I have an ancient blog post on the idea of such a starfish development workflow.)

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

#98

Post by lvh »

kibwen wrote: post #81
lvh wrote: post #39

Earlier quoted context omitted.

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.

As I've mentioned elsewhere, git is GPL, so Macs are screwed regardless. :P

git and bash3.2 are GPLv2. They didn't stop at the version of bash that was GPL; bash has always been GPL. They stopped at v3 specifically.

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

#99

Post by jdbernard »

dahart wrote: post #84
jdbernard wrote: post #68

Earlier quoted context omitted.

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

I thought git stored diffs too. But I don't understand what difference it makes, isn't the commit storage format an implementation detail? If you want to get to B from A, then I can store B or store B-A. When I have B and want to show a diff, I can calculate B-A. When I have B-A and want to show a diff, it's a no-op. When I have B and want to work, it's a no-op, but when I have B-A and want to work, I have to populat…

Maybe lvh or one of the others who has more experience with darcs of Pijul will chime in. They've probably spent more time thinking about this.

One difference is that by storing the patches only you can understand more clearly what the intended change was. When you store the whole file it is easy to compute the difference between A and B, but may be impossible to compute the correct differences between A, B, and C. By storing the whole file you now have to consider all the possible differences between them, not just the ones introduced by the commits you are trying to merge.

I would have to play around with it, but I know there are scenarios involving rebase, revert, and cherry-picking commits that can cause trouble in git that I now understand comes because of the fact that git is storing contents, not diffs.

One that I've run into regularly is cherry-picking commits from a dev branch into a master branch to hot-fix bug fixes directly into a prod release instead of waiting until dev gets merged as part of our regular process. If I had commit A on dev and cherry-pick it to master it creates a totally new commit A-1 that becomes part of the history of master. We lost the fact that A and A-1 represent the exact same changeset. Depending on what the changes are, and what further changes happen on dev afterwards, this can cause failed merges requiring manual resolution when dev does finally get merged into master.

I imagine that would not be a problem for Pijul.

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

#100

Post by mynewtb »

frant-hartm wrote: post #79
scotu wrote: post #17

Earlier quoted context omitted.

Why do you find it offputting? IANAL but it basically doesn't allow you to add code to (or get code from) Pijul itself and making it in another license. You can use it to store closed source code, you can host it yourself, offer it as a sevice for money, you can even create your own extensions as long as you release them AGPL... I feel that AGPL for a product is misunderstood and pre-rejected without justification by…

> offer it as a sevice for money Yes, you can, but if you add something - like issue tracking, user/access management etc.. around that then you need to publish that under AGPL as well.. It means it will never be part of something like github, bitbucket or AWS CodeCommit. And then there are plugins to CIs (checkout from repository ...) - would those be affected?

As long as you keep them seperate enough, via APIs or.else, no issue at all.
Post reply on HN