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

141–150 of 154 posts

Re: Commits are shapshots, not diffs

#141

Post by pmeunier »

oblio wrote: post #138
pmeunier wrote: post #128

Earlier quoted context omitted.

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

So... we're agreeing? :-) I was criticizing Git for not using diffs/patches as a regular version control user would expect.

It seems we're agreeing indeed! I understood your meant that, but I also thought you meant that snapshots were an implementation detail to simulate diffs. My point is, I don't think they're good at that.

Re: Commits are shapshots, not diffs

#142

Post by epistasis »

pmeunier wrote: post #132
epistasis wrote: post #41

Earlier quoted context omitted.

I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file, it's not enough to know just the few lines before, I need to know what versions of code are operating dozens of lines away and in different files. Further, diffs only make sense if you have the full version of the files, pre-diff. Without that full file state, diffs could operate…

> I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file,… This is somewhat contradictory. Of course, everybody works on states. But as you write yourself, you make changes to a file, you don't create a full new version from scratch every time you add a semicolon. So, if you "make changes", you actually do "work on diffs". > Further,…

I do create an entirely new state with every single semicolon, and my text editor agrees in the way that it allows me to undo and redo. As an implementation detail, these are likely stored as diffs, but since the diff is from a known start or final point, it works out OK. When we start talking about diffs that operate on different files, then everything falls apart.

Which is why I disagree heavily with the example pijul merge you linked. Since lines AB are copied directly in one edit, and the other edit adds a line X after AB, why does pijul decide that the correct merge is only adding the X line after the second instance of AB?

Viewing this in terms of diffs instead of states means that everything is ambiguous rather than clear. What does it mean to do a diff on a diff? There are many definitions and few programmers will agree on what the proper algebraic operations are, and in fact the same person will often want different algebraic operations in different settings.

In the example above, if X is a necessary cleanup step after invoking AB (e.g a file close after file open and read), then pijul's interpretation of the ambiguous situation is wrong. But if X is a summary step that's necessary only once after the double invocation of AB, (e.g. sum += read(); n += 1;) and X is, for example, mean = sum / n, then only one X is needed.

Thinking about a "diff" without tying it to a full and complete starting state will always lead to these sorts of foundational problems, and it is quite clear from this pijul example that they haven't really thought about the problem much.

Re: Commits are shapshots, not diffs

#143

Post by epistasis »

the_gipsy wrote: post #45
epistasis wrote: post #41

Earlier quoted context omitted.

I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file, it's not enough to know just the few lines before, I need to know what versions of code are operating dozens of lines away and in different files. Further, diffs only make sense if you have the full version of the files, pre-diff. Without that full file state, diffs could operate…

Your output, however, should be a patch. That's all I care about when it's time to review and integrate.

You had better care that the patch is coming from the same starting state, or else you could be wasting you time on a patch that makes no sense.

Re: Commits are shapshots, not diffs

#144

Post by pmeunier »

epistasis wrote: post #142
pmeunier wrote: post #132

Earlier quoted context omitted.

> I can't agree, because I don't work on diffs, I work on whatever the current state of the file hierarchy is. When I make changes to a file,… This is somewhat contradictory. Of course, everybody works on states. But as you write yourself, you make changes to a file, you don't create a full new version from scratch every time you add a semicolon. So, if you "make changes", you actually do "work on diffs". > Further,…

I do create an entirely new state with every single semicolon, and my text editor agrees in the way that it allows me to undo and redo. As an implementation detail, these are likely stored as diffs, but since the diff is from a known start or final point, it works out OK. When we start talking about diffs that operate on different files, then everything falls apart. Which is why I disagree heavily with the example pi…

> why does pijul decide that the correct merge is only adding the X line after the second instance of AB?

It doesn't decide, it only guarantees that the order between lines is preserved in all cases. Also, since you seem to have "thought a lot about the problem", you probably noticed that what Git does is totally wrong, since what it does depends on whether you merge both commits at once, or one at a time!

> the same person will often want different algebraic operations in different settings.

I doubt that when Alice adds line at the top of the file, while Bob edits the bottom of the file, anyone would ever want Bob's new lines merged in the middle of Alice's new lines.

Yet, that is what Git does.

> it is quite clear from this pijul example that they haven't really thought about the problem much.

Or maybe they have, and they have thought enough about it to notice that 3-way merge is doing the wrong thing, and that trying to merge snapshot doesn't even make any sense. They might have also thought enough about Git to understand that rebase is turning commits into patches, one by one, in order to "replay them on top of the current version".

While I do agree that full versions are important for storage (and all version control systems, including patch-based ones, are able to recover full versions), they are not very useful to merge work, or to solve conflicts.

Re: Commits are shapshots, not diffs

#145

Post by gnufx »

pmeunier wrote: post #121
gnufx wrote: post #91

Earlier quoted context omitted.

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

I'd still like to know if you're claiming Darcs 3 (which may or may not be at a similar stage of development) still has that issue (which I don't remember biting me). I've no particular axe to grind as a Darcs user, as long as I have a nice patch-based system.

Re: Commits are shapshots, not diffs

#146

Post by gnufx »

pmeunier wrote: post #124
jgalt212 wrote: post #81

Earlier quoted context omitted.

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

To be fair, Roundy's idea of commutation was novel in 2002 (unless it was a reinvention of something earlier, which wouldn't surprise me) whether or not it was done right then. I'm happy if Pijul improves something which definitely simplifies workflows and doesn't get me confused after 30 years of revision control and sometimes resorting to diffs.

Re: Commits are shapshots, not diffs

#147

Post by pdonis »

pmeunier wrote: post #128
oblio wrote: post #71

Earlier quoted context omitted.

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

> snapshots don't model diffs properly

Of course a single snapshot can't model diffs properly, since a diff is a property of a pair of snapshots.

Your examples of how git doesn't treat things properly look to me like cases where git is picking the wrong pairs of snapshots to generate diffs.

Re: Commits are shapshots, not diffs

#148

Post by rualca »

throwawayzRUU6f wrote: post #119
rualca wrote: post #103

Earlier quoted context omitted.

> Underlying technology aside, mercurial has (I think) quite objectively better cli interface. I disagree. The fact that mercurial relied extensively on extensions to implent basic features, thus exposing a non-standard interface to the world, made it's mental load significantly higher than simply using a standardized (albeit debatable) interface to do standard things. Case in point: requiring installing extensions t…

> relied extensively on extensions to implent basic features Sorry, this is a strawman. Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed, while working more than 7 years on reasonably complex projects spanning about a dozen teams, in multiple timezones and repositories. And it takes less than 5 minutes to install. We were forced to move to Git after being acquired, and whil…

> Sorry, this is a strawman.

It really isn't,and you cannot hide Mercurial's failings by trying to move the goal post.

It's a fact that Mercurial's non-standard interface created a mental load for basic ops that is considerably higher that git's reliable and predictable (and, more importantly, learnable) interface.

> Yes, `hg shelve` is a very nice extension. But that's about the only add-on I've ever needed.

It's not a "nice extension". It's core functionality, which is a part of any basic introductory workflow.

And with mercurial instead of just being able to stash changes with a simple $ git stash , all of a sudden you need to bother with installations and setups and configs and checking if everything is it's place.

Just. To. Stash. A. Change.

And if you find stashing nothing more than "a nice extension", and nothing else pops into your mind, then you clearly have limited experience in using revision control systems.

> And it takes less than 5 minutes to install.

Did you failed to notice that it forces you to waste time ensuring you're bolting on all the stuff you need whenever you jump a seat or pop into an instance?

And did you failed to realize this problem is not experienced with pretty much any revision control system? Not just git, but pretty much all of them.

Re: Commits are shapshots, not diffs

#149

Post by pmeunier »

gnufx wrote: post #145
pmeunier wrote: post #121

Earlier quoted context omitted.

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

I'd still like to know if you're claiming Darcs 3 (which may or may not be at a similar stage of development) still has that issue (which I don't remember biting me). I've no particular axe to grind as a Darcs user, as long as I have a nice patch-based system.

I don't think Darcs 3 was even started. Darcs 2 recently solved the exponential merge, but it is now quadratic (which is still exponentially slower than Pijul instead of double-exponentially).

I've also been really happy with Darcs, expect for two things:

- Conflicts are not handled very well, as if they were not properly stored internally. `darcs revert` on a conflict doesn't always do what I expect.

- The fact that it doesn't scale (even with the quadratic algorithm) means that big users can't adopt it, which means that too few people write tools for it (including a hosting website: I'm aware of hub.darcs.net, but there are many things missing, including on security). Darcs is hard to install on platforms such as Windows. Also, few people know it, which means that it's hard to collaborate using it.

Re: Commits are shapshots, not diffs

#150

Post by pmeunier »

geofft wrote: post #65
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 don't think diffs are the "natural" object - if you talk to someone who isn't using an automated version control system but still doing revision control, what they have is "Resume 12-1-2020.doc," "Resume 12-2-2020.doc," "Resume reviewed by Joe.doc," "Resume for Contoso final.doc," "Resume for Contoso final final USE THIS VERSION.doc," etc. Those are snapshots of individual versions of the files, not diffs. Or think…

All the arguments you give are based on shortcomings of the tools: Microsoft Word doesn't have version control, Wikipedia stores versions in a database.

> But the ultimate goal is to produce a version of the file.

The fact that the end result is a version doesn't mean versions should be the main object. If you add a semicolon to a file, the actions you do are "press the ; key", not "create an entire version from scratch that has a semicolon there".

> If you want a diff management system, play around with quilt

You're doing it again! Why pick the least suitable tools for the jobs? Quilt is not a patch-based version control system, Pijul and Darcs are.

Post reply on HN