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.
Commits are shapshots, not diffs
91–100 of 154 posts
Re: Commits are shapshots, not diffs
#92A 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…
Re: Commits are shapshots, not diffs
#93So 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
#94Git 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…
Re: Commits are shapshots, not diffs
#95When 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…
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
#96When 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…
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
#97Snapshots 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.
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
#98Earlier 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.
Re: Commits are shapshots, not diffs
#99When 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…
It's exactly what revision control does and helps you to accomplish. What do you think revision control is for if not that?