Live data from Hacker News

The Architecture of Git (2012)

aosabook.org

31–40 of 85 posts

Re: The Architecture of Git (2012)

#31
post #7

The best (known to me) informal intro into the architecture of Git is The Git Parable: http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...

Also greatly worth reading: “Git from the Bottom Up”:

* HTML version: https://jwiegley.github.io/git-from-the-bottom-up/

* PDF version: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf (via http://newartisans.com/2008/04/git-from-the-bottom-up/)

The great thing is that after reading and understanding these, one's mental model matches the reality of the Git program, so one can both try bolder things, and get unstuck from any mess.

Re: The Architecture of Git (2012)

#32
post #29

Earlier quoted context omitted.

> Which is the VCS most suitable for .... Git. It doesn't matter what your question is. :-) I mean, come on, it's not like you have a choice. You gotta use whatever your teammates/coworkers/organization is using. That said, yeah, there's a lot of pedagogic problems with git stemming from the INSANE inconsistency of command-line. The only redeeming quality? It works and it's popular.

People once said that about Subversion. I believe Mercurial has a chance if they get support for large binary files right before git does.

Subversion wasn't a distributed VCS. Anything looking to displace git would have to make that kind of generational leap for the existing userbase to be remotely interested.

Re: The Architecture of Git (2012)

#35
post #29

Earlier quoted context omitted.

People once said that about Subversion. I believe Mercurial has a chance if they get support for large binary files right before git does.

Subversion wasn't a distributed VCS. Anything looking to displace git would have to make that kind of generational leap for the existing userbase to be remotely interested.

Being distributed is really more of a 00s concept anyway. It makes total sense that distributed systems would be replaced with more centralized ones as the internet itself goes through a similar transition.

Re: The Architecture of Git (2012)

#36

I'm surprised that it's not mentioned in the article that one of the most interesting architectural aspects of git is that it's a blockchain system.

That's arguably not the most interesting architectural aspect of Git.

Or does any back-linked tree data-structure becomes interesting if the nodes keep a hash of their parent instead of a raw reference? I don't think that's the case.

It might be a bit heretical but I don't think Git has a super interesting internal architecture. I'm not downplaying the fact that Git was very innovative, especially considered the landscape of SVMs at the time. The tool as a whole is great and has desirable properties but its internals don't strike me as particularly innovative. It's a clever composition of solutions to well established problem domains. And in that aspect it is a beautiful engineering solution although there is room for a lot of improvement in terms of UX.

And in addition to that, I would argue that it would be a very weak definition of "blockchain". The innovation in Bitcoin is the incorporation of proof-of-work and resulting alignment of incentives such that it can achieve probabilistic consensus in an adverse setting and with some degree of asynchronicity.

The underlying structure of the data is an obvious choice because it is simple and "captures" the idea of aggregate global state, but it's also hardly an important innovation. UTXOs are more significant.

And also, recall that the textbook example for state-machine replication is always an append-only log for example. So that's not the crux of it, or of blockchain, in my humble opinion.

Re: The Architecture of Git (2012)

#37
post #5

Git is the VCS most suitable for bottom-up learners. Which is the VCS most suitable for top-down learners?

> Which is the VCS most suitable for .... Git. It doesn't matter what your question is. :-) I mean, come on, it's not like you have a choice. You gotta use whatever your teammates/coworkers/organization is using. That said, yeah, there's a lot of pedagogic problems with git stemming from the INSANE inconsistency of command-line. The only redeeming quality? It works and it's popular.

I really hope Git isn't the end of the road for VCS. I work in visual effects and video games. Most video game studios still begrudgingly use Perforce for project data. Many also have a separate Git server for code. Perforce or SVN is still the go to solution for binary assets. Trying to explain Git to programmers is difficult enough, for artists who have never used the command line it is unreasonable. Every time I've seen an "asset library" it's usually written from scratch instead of built on another VCS. I've made some crude attempts at building on Git and the data just structure isn't appropriate.

I know it's a bit unreasonable to expect the same tool for everything (but that's what you were implying). The binary problem is more manageable for code with a few UI assets (like icons), but isn't great.

Re: The Architecture of Git (2012)

#38
post #7

The best (known to me) informal intro into the architecture of Git is The Git Parable: http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...

> After using branches for a while you notice that they can serve two purposes. The first use case allows you to keep track of ongoing development, things like “Release Maintenance”. The second case is useful for labeling points of interest, like “Version 1.0” and “Version 1.0.1”.

> For the sake of clarity and elegance, you decide to create another file called tags to contain pointers of the second type. Keeping these two inherently different pointers in separate files will help you from accidentally treating a branch as a tag or vice versa.

Ah, ha ha ha ha ha ha ha ha ha ha ha.

If "tags" and "branches" were the same thing, but just conventionally separate uses, that would be great.

If only that was the way git treated them.

Re: The Architecture of Git (2012)

#40
post #39

Not sure if it’s of any relevance but I recently discovered https://gitup.co and must say, it’s pretty cool.

Frickin' amazing UI design, and some great pieces of functionality (edit the commit graph directly; ability to undo most operations).

Unfortunately development seems mostly paused, and it still has some big gaps...

Still tho by far my favorite git client. (#2 would be Sublime Merge.)

Post reply on HN