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

71–80 of 154 posts

Re: Commits are shapshots, not diffs

#71

Post by oblio »

pdonis wrote: post #62
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.

> 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.

Re: Commits are shapshots, not diffs

#72

Post by zokier »

aidos wrote: post #24
recursive wrote: post #3

I have never understood cherry-pick for this very reason. This helps, but I'm still confused. > The git cherry-pick command creates a new commit with an identical diff to whose parent is the current commit. How can two diffs ever be considered equivalent when they include a changed file that had different starting contents? Can they?

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

#74

Post by searealist »

fuzzybear3965 wrote: post #69
ldite wrote: post #68

Earlier quoted context omitted.

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.

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.

Re: Commits are shapshots, not diffs

#75

Post by lilyball »

Even though I knew everything about the internal structure already, reading this post was worth it for learning about `git range-diff`, which I'd never heard of before. This sounds exactly like a tool I've always wished Git had.

Re: Commits are shapshots, not diffs

#76

Post by oblio »

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…

You're right but I think what you're describing the absolute bare minimum of version control. Yes, people want to ostensibly see the different versions/states. But for anything past the simplest setups, they immediately want to see changes, since you're actually after change management, not version control. Viewing different versions scales very poorly. Even regular user oriented tools such Word offer "Track changes", which is a diff view. Wikipedia also has a "Compare versions" button quite prominently on the page you mention.

If anything, most users I've exposed even to simple diff tools immediately appreciate the value. It's just that mainstream tools rarely support diffing since it's very complex from a technical point of view (end user tools and apps rarely work with plain text, they use binary formats, marked up text, etc), so it's not a mainstream paradigm as a result, and people are less familiar with it.

Re: Commits are shapshots, not diffs

#77

Post by pdonis »

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.

> It can use ponies

This I would like to see. :-) Particularly the part about defining a protocol for sending messages over the Internet using ponies (there already is one for pigeons...)

Re: Commits are shapshots, not diffs

#78

Post by feoren »

espadrine wrote: post #70

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…

I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.

Re: Commits are shapshots, not diffs

#79

Post by war1025 »

feoren wrote: post #78
espadrine wrote: post #70

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…

I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.

> Mercurial is so much simpler and easier to understand than Git

I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way.

But git was already gaining significant traction when I started using version control.

I can see how having built your mental models around previous version control systems and then trying to superimpose that on git would cause dissonance.

But my entire concept of version control is based on how git does it, so it seems perfectly natural.

Post reply on HN