Live data from Hacker News

Commits are shapshots, not diffs

github.blog

91–100 of 154 posts

Re: Commits are shapshots, not diffs

#91
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.)

Re: Commits are shapshots, not diffs

#92

A fascinating bit of history is that the reason for this data structure was to explicitly distance git from BitKeeper. BitKeeper was used by many kernel developers, until one of them (the co-inventor of rsync, unsurprisingly) reverse-engineered its protocol, leading its proprietary owner to end its offer of a free license to Linus Torvalds and other developers. While searching for a replacement, the Linux community s…

Isn't Mercurial different only in nomenclature? The manifest id stored in a changeset is a tree snapshot. Otherwise I don't think hg-git would work as transparently as it usually does.

https://www.mercurial-scm.org/wiki/ChangeSet

Re: Commits are shapshots, not diffs

#93
When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folders tagged with some details. Each folder is a commit'. People understand very easily how to keep copies of their work at a given time by simply coping the full folder (probably we all did this before using git).

So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way.

The issue is that some advanced (and not so advanced) commands, like a merge, aren't easily explainable with this metaphor, and that's when the 'commits are also diffs', or better 'commits can be seen as diffs' is needed.

Re: Commits are shapshots, not diffs

#94
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…

That's a significant bar, which doesn't apply to Darcs and Pijul.

Re: Commits are shapshots, not diffs

#95

When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folders tagged with some details. Each folder is a commit'. People understand very easily how to keep copies of their work at a given time by simply coping the full folder (probably we all did this before using git). So yes, a commit is just a snapshot, a copy, it i…

> So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way.

Not really. Although it might be helpful to explain to someone entirely new to git that a commit marks a revision, and a revision is kind of a copy of a project folder, that mental model has no bearing to what a revision control does or helps you accomplish.

I mean, as soon as you talk about diffs and branches and cherry picks and merges then thinking about copies of a folder spread around does not explain what's happening.

And what's the point of git if not to track and manage diffs?

Re: Commits are shapshots, not diffs

#96

When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folders tagged with some details. Each folder is a commit'. People understand very easily how to keep copies of their work at a given time by simply coping the full folder (probably we all did this before using git). So yes, a commit is just a snapshot, a copy, it i…

Yeah. That's a perfectly valid form of version control. You could tell them to imagine renaming the directory each time with an incrementing number. That's the version number, hence version control.

Merge can be explained too. Say you send the folder to your friend and that night you both make a new version. If you want to consolidate your changes you have to merge them together. I don't see why this requires commits to be seen as diffs.

Rebase is a bit more tricky. Maybe that's what you were thinking of?

Re: Commits are shapshots, not diffs

#97
post #50

Snapshots and diffs are just a storage implementation detail, no? Can you not calculate one from the other?

> Can you not calculate one from the other? Yes, you can. > Snapshots and diffs are just a storage implementation detail, no? If this is what you think, the headline is truly awful; git commits are stored as diffs where possible.

It’s more complicated than that!

Packfiles use delta compression to store repositories more compactly, but the deltas are not at all related to commits. The objects (blobs, trees, etc.) are sorted for similarity, completely ignoring the graph of commit history and completely ignoring filenames or directory structures, then delta compression is applied. This allows git’s storage to be smaller than version control systems that use a storage structure that preserves history or filenames.

Re: Commits are shapshots, not diffs

#98
post #72
post #24

Earlier quoted context omitted.

I find it easiest to think in terms of diffs as patches. It’s just a bunch of search and update commands. Sure, there’s some hairiness around files moving or whatever, but for me, a cherry pick is just getting a patch file and applying it in the appropriate place. It doesn’t care about the file it’s being applied to, it just needs to find similar content in the file so it can apply itself.

Yeah, git cherry-pick is basically just git diff | git apply. And rebase is just cherry-picking many commits.

Exactly. And the other day I did exactly that with piping diff through apply so I had more control over conflicts I was hitting. Suspect all the years in svn just make it easier for me to think of it that way rather than some magical operation.

Re: Commits are shapshots, not diffs

#99
post #95

When I need to explain git to someone for the first time I always start with the 'imagine you are copy/pasting your project folder, and you have multiple folders tagged with some details. Each folder is a commit'. People understand very easily how to keep copies of their work at a given time by simply coping the full folder (probably we all did this before using git). So yes, a commit is just a snapshot, a copy, it i…

> So yes, a commit is just a snapshot, a copy, it is simply saved in a much more efficient way. Not really. Although it might be helpful to explain to someone entirely new to git that a commit marks a revision, and a revision is kind of a copy of a project folder, that mental model has no bearing to what a revision control does or helps you accomplish. I mean, as soon as you talk about diffs and branches and cherry p…

> that mental model has no bearing to what a revision control does or helps you accomplish.

It's exactly what revision control does and helps you to accomplish. What do you think revision control is for if not that?

Post reply on HN