Live data from Hacker News

Git can't be made consistent

bramcohen.livejournal.com

41–42 of 42 posts

Re: Git can't be made consistent

#41
post #40
post #33

Earlier quoted context omitted.

Why do you think he's using the term incorrectly? He just means that, with git, the order in which you apply patches matters. In a scenario where people are distributing patches and applying them as they receive them, this implies a lack of eventual consistency.

That's the lack of the associative property. Eventual consistency means that updates will eventually be propagated to all replicas in a distributed system and that all replicas will be consistent. Not the same thing, at all.

Commutative, not associative. And the commutative property is exactly what's required to guarantee eventual consistency when patches are being applied in the order they are received since it ensures that order of application doesn't matter. Of course, if you have all of the updates, you can achieve eventual consistency without commutativity by periodically reapplying all of the patches from scratch in a deterministic order. But IMO his intended meaning was both clear and correct.

Re: Git can't be made consistent

#42
post #30
post #28

Earlier quoted context omitted.

Git also stores diffs from time to time: http://book.git-scm.com/7_how_git_stores_objects.html

I'm guessing you're referring to packed objects. If I understand them correctly they are just there for space efficiency of the filesystem that is git . They're not first order concepts on which git the DVCS builds upon, just an implementation detail.

My thinking when I posted my comment above was that any diff format used in the repository could be treated as an "internal" format, and any actual merges that you perform could use any merge strategy that they like, as long as the commit code converted it into the repository's format on the way in. Which is why I pointed out that git also uses an internal diff format. However, if your point is that hg uses an internal format which cannot store particular changes to files correctly, or requires excessive engineering, then yes, that would be a problem and I see where you are coming from. I do very much like the conceptual simplicity of git.
Post reply on HN