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

111–120 of 154 posts

Re: Commits are shapshots, not diffs

#111

Post by Pet_Ant »

kelnos wrote: post #109
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.

I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeepe…

> The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeeper client revoked. (And reverse engineering BK's protocol was also forbidden.) From the starting line I already thought he was slimy for that.

I'm letting you use my commercial product under the understanding that you won't try to undermine it... I think that's actually pretty reasonable. I'm giving you something for nothing in return, and all I ask is not to try to take more from me? I always though that Tridge was ungrateful in the situation.

Re: Commits are shapshots, not diffs

#112

Post by deathanatos »

phailhaus wrote: post #22
mcc1ane wrote: post #6

Is it normal to need that level of understanding of the inner machinery of a software to use it?

I don't quite agree with the author that you need to understand that commits are implemented as snapshots, but yes, you need to understand quite a bit of how git works behind the scenes in order to use it effectively. This is because git tries to hide more than it should, which leads to confusion when things Go Wrong.

I'd also say that when I've worked through people's confusion surrounding git (and other complex systems, it is because they are attempting to model the system as simpler than it actually has to be. They're not thinking of cases the system must handle, and in the absence of that (essential) complexity, they come up with an incorrect mental model that they believe works (as they're not aware of the counter-examples to it).

This happens often. As another example, a former PM of mine used to assume that if our wearable recorded heart-rate data, it also had sweat data. That is, the wearable either had a lock, and recorded, or didn't. But sweat came from a different sensor than HR, and the two sensors could independently get or lose their signal. And so, sometimes one was null, sometimes the other, sometimes both, sometimes neither.

Re: Commits are shapshots, not diffs

#113

Post by lowbloodsugar »

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.

I know git is confusing on the one hand, and somehow instills over-confidence on the other. But the underlying implementation of "Store everything, SHA it, and build a merkel tree" is, in my opinion, the kind of thoroughness I want in a version control system.

Re: Commits are shapshots, not diffs

#114

Post by ninkendo »

tsimionescu wrote: post #55
recursive wrote: post #13

Earlier quoted context omitted.

I kind of intuitively get it, but that doesn't really seem well defined. I'm always a little bit spooked that `cherry-pick` will cleanly apply when it really shouldn't have. It's not clear to me under which circumstances it automatically resolves.

You're right to be spooked about that, but you're wrong if you think only cherry-pick has this problem. In fact, all git commands can and sometimes will cleanly apply and subtly mess your files (git merge, git pull, git rebase, git apply, git stash apply etc). The definition of how changes are applied actually has nothing to do with git itself, and everything to do with the diff algorithm you choose (of course, you n…

You don’t even need to think about diff algorithms to see why a cherry-pick, merge, etc may not do what you want.

If in my branch, I rename oldFunc to newFunc in file A, and change file B to replace the call to oldFunc with newFunc; and in your branch, you add a new call to oldFunc in file C... the code will break when we merge our branches. Our changes would both pass tests independently, but would break when we merge them. No file-level diff algorithm would detect a “conflict” here.

Diff algorithms only help with saying “are two branches trying to edit the same lines of code”, but the answer to that question is never enough to tell you whether two changes logically will apply cleanly to one another.

Re: Commits are shapshots, not diffs

#115

Post by em-bee »

kelnos wrote: post #109
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.

I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeepe…

This is where Torvalds should have gotten his big honking "I told you so", but I expect he took the wrong lesson from it

which lesson did he take and what should he have learned instead?

Re: Commits are shapshots, not diffs

#116

Post by Rexxar »

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.

Replace letters by line of codes and it will have the same result.

Re: Commits are shapshots, not diffs

#117

Post by brodie »

mkj wrote: post #92
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…

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

They’re different in the their implementations of how repositories are stored on disk. Other than that, you’re right in that the two systems have a gigantic (almost one to one) abstract/conceptual overlap.

Re: Commits are shapshots, not diffs

#118

Post by brodie »

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.

Short of breaking backwards compatibility at this point, there’s nothing preventing Git from being as simple as Mercurial CLI-wise. The two projects are nearly identical on a high level.

Re: Commits are shapshots, not diffs

#119

Post by throwawayzRUU6f »

rualca wrote: post #103
yoz-y wrote: post #87

Earlier quoted context omitted.

Underlying technology aside, mercurial has (I think) quite objectively better cli interface. All flags are the same among commands, and all commands have their undo counterparts.

> 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 while the migration was painless, the day-to-day friction caused by Git porcelain is notably higher than with Mercurial. The issues caused by line-endings alone waste more time than all the Mercurial issues combined.

Re: Commits are shapshots, not diffs

#120

Post by [deleted] »

DoofusOfDeath wrote: post #83
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 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.

[deleted]
Post reply on HN