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

Commits are shapshots, not diffs

github.blog

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Commits are shapshots, not diffs

#121

Post by pmeunier »

gnufx wrote: post #91
dilap wrote: post #20

This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.

Pijul patches can't be just diffs. I don't know the Pijul implementation but you can see what they're like in Darcs, for instance, in the text form they're meant to be mailed. (Darcs isn't alpha, nothing against Pijul.)

They're not just diffs indeed, they have a bit more information, see an example there:

https://nest.pijul.com/pijul/pijul/changes/XTMYHJZLWWT5I2PJA...

First, there are explicit dependencies, and also each section starts with a somewhat cryptic machine-readable description, for example:

B:BD[2.1195] → [2.1195:1291]

One of the challenges in the new version of Pijul was to find a description that was printable in text, and not too-unintelligible to humans.

Darcs isn't alpha, but merges patches in exponential time, which was the initial motivation for Pijul.

Re: Commits are shapshots, not diffs

#122

Post by ben509 »

espadrine wrote: post #86
DoofusOfDeath wrote: post #83

Earlier quoted context omitted.

I forget - was there another side to the story that made McVoy's actions seem more reasonable? If all I had to go on was Bryan O'Sullivan's email, I'd be tempted to draw some unflattering conclusions about McVoy's conduct.

Mercurial was officially named after Larry McVoy. (No idea about git.) That said, in his defense, causing the creation of multiple open-source competitors to one’s moneymaker can be stressful.

> (No idea about git.)

Quoth wikipedia[1]:

> "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'."

[1]: https://en.wikipedia.org/wiki/Git#Naming

Re: Commits are shapshots, not diffs

#123

Post by pmeunier »

rualca wrote: post #105
dilap wrote: post #20

This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.

> (...) and you avoid all of the rebase/cherry-picking craziness of Git. What's that rebase/cherry-picking craziness?

> What's that rebase/cherry-picking craziness?

I can only guess what OP had in mind: when you rebase in Git, commits are "replayed" on top of other commits. But there's no way this replay can really work, for two reasons:

- conflicts are not even modeled in commits, which is why some solve conflicts can come back. You may say this never happens, but (1) the problem is so real that Git even has a `git rerere` command to fix it, and (2) many workflows have explicit ways of avoiding this situation: no matter what your natural workflow is, you must adapt it to suit Git.

- each step of the replay tries to commute patches, but Git uses 3-way merge for that, and this is not a 100% algorithm, merely a heuristic, as explained there: https://pijul.org/manual/why_pijul.html

Re: Commits are shapshots, not diffs

#124

Post by pmeunier »

jgalt212 wrote: post #81
dilap wrote: post #20

This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.

If you get a bad merge, why not just layer on a series of diffs? In short, a pijul/diff based front end merge tool to git, hg, etc to assist with any challenging merges.

You could certainly do that, and this is in fact one of the ways to use Pijul. However, you would completely miss out on the most important novelty of Pijul, which is patch commutation:

When we say "Pijul is patch-based", we don't only mean that it stores patches, but rather that patches that could be written independently commute, meaning that they can be applied in any order, and are guaranteed to give the same result in all cases (including when they conflict).

This simplifies many workflows.

Re: Commits are shapshots, not diffs

#125

Post by pmeunier »

searealist wrote: post #74
fuzzybear3965 wrote: post #69

Earlier quoted context omitted.

Are you sure about that? See "Why a new version control system?" at https://pijul.org/faq/ and the linked "badmerge" example: https://tahoe-lafs.org/~zooko/badmerge/simple.html

If a project wants to hold up a bad merge as an example why they are better. They need to do better than just a list of letters. They need an actual example of real code.

Actually, I wrote the graphical version of that example (the original authors are cited). I find that the code version is harder to understand. The letters make it much more explicit that Git is really shuffling lines around (I find that scary).

Re: Commits are shapshots, not diffs

#126

Post by pmeunier »

ldite wrote: post #68
dilap wrote: post #20

This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.

There's nothing intrinsically superior about storing commits as diffs - subversion stores its commits as diffs (or at least, it did a decade or so ago,) and I haven't heard anyone enthusing about svn in a long time.

That's right, and actually Pijul patches are not actual diffs, they just behave exactly like them for all uses.

The main thing I believe is intrinsically superior to Git (I use Pijul a lot) is patch commutation, not just patches. Pijul guarantees that two patches that could be written independently always commute.

This has important consequences:

- You can push patches from the same branch in any order (provided they don't depend on each other). This wont change their identity, meaning that if you decide to push the other patches later, you can do it without having to rebase, and review/test the new order.

- Conflicts happen between patches, and conflict resolutions are modeled as patches. This means that if you solve a conflict once, you can push your resolution, even if you have your own, private patches on the same branch.

Re: Commits are shapshots, not diffs

#127

Post by pmeunier »

tener wrote: post #46
oblio wrote: post #9

Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.

Snapshots and diffs are dual. Most version control systems operate on snapshots, but there is at least one that doesn't: Darcs. Written in Haskell, it bases it's operation on an algebra of patches. Unfortunately, while usable (and neat!) for smaller projects, Darcs has serious performance problems (due to inherent algorithmic complexity) and gets slower with certain operations. Still, one can hope it will inspire a n…

This is not inherent to the patch model, just to Darcs' algorithm. Pijul (pijul.org) doesn't have these problems, and is indeed quite fast. The main limitation at the moment is merging very large histories, which has the same complexity as a Git rebase at the moment (this will be fixed).

Re: Commits are shapshots, not diffs

#128

Post by pmeunier »

oblio wrote: post #71
pdonis wrote: post #62

Earlier quoted context omitted.

> Diffs are a "natural" object for version control Diffs are natural objects for evaluating commits--answering questions like "does this new version of the code make sense?"--but they are not the natural objects for storing commits.

To expand, since we agree. Diffs are "natural" objects for users of source control. Diffs are not natural objects for storing anything since that's not the job of the users, it's the job of the version control system. It can use ponies to store the "controlled versions" for all I (and probably other users) care.

I don't know about ponies, but for snapshots, I disagree: snapshots don't model diffs properly, and many operations in Git are essentially trying to simulate patches:

- Merge and rebase both try to "replay" patches. But because Git doesn't work with patches, it actually only simulates that, using heuristic algorithms such as 3-way merge. This works most of the time, but not always (see https://pijul.org/manual/why_pijul.html).

- Conflict resolutions in Git cannot be modeled as patches, and you need `git rerere` to simulate that. This is not anecdotal, since conflicts is the one situation where you need the best and most intuitive tool.

- Short-lived branches are another poor simulation of patches: if Git were really working on patches, you would be able to create a branch "after the fact", meaning that you would work (possibly on multiple features at the same time), and push different parts of your work separately, without having to worry about branches before you start.

Re: Commits are shapshots, not diffs

#129

Post by pmeunier »

smcameron wrote: post #32
oblio wrote: post #9

Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.

And good thing it's leaked, as anyone who's ever maintained, say linux kernel drivers for multiple distros knows. Easy to maintain a stack of commits on Linus's kernel and patch them into the various distro kernels. Well, for some value of "easy". But it would be a hell of a lot harder if you didn't have access to diffs and what I think of as "patch arithmetic." (i.e. source - patch3 + patch1 + patch2 == source + pat…

> Patches are commutative (barring conflicts).

That isn't quite true, even without conflicts. The same example that shows that Git merge is not associative (https://pijul.org/manual/why_pijul.html) can be used to show that it also isn't commutative.

Re: Commits are shapshots, not diffs

#130

Post by pmeunier »

chubot wrote: post #15
oblio wrote: post #9

Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.

I'd argue that diffs in the presence of renames aren't natural, and git handles them better than other version control systems. That is, git is content-based and not named-based. Name-based systems explicitly track renames with metadata; git does not. git calculates renames dynamically based on content.

> I'd argue that diffs in the presence of renames aren't natural, and git handles them better than other version control systems.

Maybe this is because I designed that part in Pijul, but I disagree. Pijul has renames commute with other types of edits, and renames are faithfully modeled in Pijul patches, not just "guessed" after the fact based on contents.

Post reply on HN