Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Architecture of Git (2012)

aosabook.org

Post reply on HN
Print view View original

61–70 of 85 posts

Re: The Architecture of Git (2012)

#61

Post by 4ad »

pfranz wrote: post #51
CodeMage wrote: post #50

Earlier quoted context omitted.

Based on my brief stint in the game development industry, it seems that there are two major obstacles that keep artists from adopting Git. One is the tooling: most of the tools artists use have integrated support for Perforce. This problem is not trivial, but it's something that could ultimately be overcome. A much bigger obstacle is the workflow. The reason why coders can work with a DVCS is because merging in other…

In practice, most people don't expect binary files to diff or merge. It's more about how mergeable groups of files or commits are. I've seen a few tools that diff certain image formats, which can be helpful, but I don't think this is all that different than what Git does with text. I agree that the bigger issue is workflow. Often after setting them up I get asked for a checkout/locking model because that's easier to…

> To be fair, I don't see indie studios bothering with Perforce, either.

What then? SVN?

Re: The Architecture of Git (2012)

#62

Post by macintux »

reificator wrote: post #26
ThrowawayR2 wrote: post #23

Earlier quoted context omitted.

I'm a bit disappointed by the flippant replies. Mercurial is a very solid alternative VCS (Facebook uses it internally) and is friendlier (or at least has less gotchas) than git.

As a flippant replier, it's partly motivated by not really thinking other VCSes have a chance. As confusing to use as Git's UI may be, I think the only way we're getting away from it is if someone massive pushes an alternative. Alexa.com has Github trending down six places to the 66th most visited page on the internet. Worldwide. That's not just programmers that's everyone.

> not really thinking other VCSes have a chance

There's no reason the world has to universally adopt one true VCS.

Re: The Architecture of Git (2012)

#63

Post by vram22 »

I had come across this gem about understanding the vi editing model a while ago:

"Your problem with Vim is that you don't grok vi."

It's the top answer on this StackOverflow question:

What is your most productive shortcut with Vim?

https://stackoverflow.com/questions/1218390/what-is-your-mos...

Wonder if there is any such post about Git that cuts to the chase, even for a part [1] of the Git model, and explains it clearly [2].

[1] I had also come across a StackOverflow post that explains a part of git very clearly, like the vi example I quoted. I think it was about how to roll back accidental changes using "git reset --hard" and variants. Saved it, but don't have it handy right now.

[2] Note: I said "clearly", not necessarily "simply". I like to quote the (probably out-of-print) book by Abbe Dimnet [3] called The Art of Thinking, in which he said something like this (while deploring the trend of books that try to make things artificially simple, a.k.a. dumbed down):

"French grammar cannot made simple. It can be made clear."

[3] https://en.wikipedia.org/wiki/Ernest_Dimnet

He also wrote a book on that same topic (French grammar made clear). Googled the former book recently and saw about the second book. I've read the first, long ago, which I found in a second-hand bookshop. Good book. Apparently it was a best-seller at the time it came out, according to Wikipedia.

Quotes by him:

https://en.wikiquote.org/wiki/Ernest_Dimnet

Re: The Architecture of Git (2012)

#64

Post by Born_Again »

sfescape wrote: post #55
ysleepy wrote: post #44

Earlier quoted context omitted.

It's a merkle tree, not every hash tree or chain is a blockchain thing. IMO blockchain describes the combination of a hash chain and the no-trust agreement protocol on top.

I don't agree with that. The oldest blockchain known has its hash codes published each week in the New York Times. I would agree that having the ability to prove the history hasn't been modified by externally retaining the hashes could be a component, but git qualifies for that as well.

I would recommend reading the Wikipedia article for a blockchain [0]. It's agreed that a blockchain is decentralized and resistant to change from bad actors. If a system doesn't meet those requirements, it's just a fancy database. I don't see how Git or the New York Times example you mentioned are inherently decentralized.

[0] https://en.wikipedia.org/wiki/Blockchain

Re: The Architecture of Git (2012)

#65

Post by freshhawk »

svat wrote: post #31
nine_k wrote: 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 uns…

I recommend this constantly, it is excellent.

Not to outright beginners, but anyone past that point should read this. It is a great job of clearly presenting an accurate mental model that helps you use git. If you are already a git expert this is just a good thing to learn from in general and with how to explain and teach git usage in particular.

The only documentation I know of that can turn people from cargo cult git users to people who just do the version control things they need done with the parts of git they need. That is damn useful.

Re: The Architecture of Git (2012)

#66

Post by xrd »

agbell wrote: post #33
xrd wrote: post #14

I still prefer my book's history of Git in which I compare Linus rejection of Monotone to the movie "Back to the Future": https://github.com/xrd/BuildingToolsWithGithubBook/blob/ca7f...

Interesting, what am I reading?

This (a book about building tools with Git and the GitHub API) was published by O'Reilly in 2016, and we just released it under creative commons. You can read it completely free at https://buildingtoolswithgithub.teddyhyde.io or get the repo of the book contents above.

Re: The Architecture of Git (2012)

#67

Post by pfranz »

4ad wrote: post #61
pfranz wrote: post #51

Earlier quoted context omitted.

In practice, most people don't expect binary files to diff or merge. It's more about how mergeable groups of files or commits are. I've seen a few tools that diff certain image formats, which can be helpful, but I don't think this is all that different than what Git does with text. I agree that the bigger issue is workflow. Often after setting them up I get asked for a checkout/locking model because that's easier to…

> To be fair, I don't see indie studios bothering with Perforce, either. What then? SVN?

Nothing. If you're lucky they'll have their own obtuse naming structure of "carrot_model_FINAL_FINAL_12.psd" With something like Unreal Engine, Maya, Photoshop, etc. you can get a few knowledgable artists and build a game with minimal technical skill. If it's not as turnkey as using Dropbox or Windows Backup, they probably won't use it.

I started at a place in 2011 that had been open since 1993 and had spun off some software that is industry standard. They were proud they had recently got everyone using SVN. For the entire life of the company teams used whatever they wanted and most used nothing. They're still using SVN.

Re: The Architecture of Git (2012)

#68

Post by 4ad »

pfranz wrote: post #67
4ad wrote: post #61

Earlier quoted context omitted.

> To be fair, I don't see indie studios bothering with Perforce, either. What then? SVN?

Nothing. If you're lucky they'll have their own obtuse naming structure of "carrot_model_FINAL_FINAL_12.psd" With something like Unreal Engine, Maya, Photoshop, etc. you can get a few knowledgable artists and build a game with minimal technical skill. If it's not as turnkey as using Dropbox or Windows Backup, they probably won't use it. I started at a place in 2011 that had been open since 1993 and had spun off some…

I don't understand how it is possible to work like this. As soon as I started learning programming I immediately wished for and imagined some kind of version control. I didn't have to imagine much, as I very quickly learned about cvs (the standard back then).

My partner, a scientist, that deals with all kind of data and code and latex has expressed the need for version control too (sadly I have not been able to explain git well enough such that it makes enough sense so she could use it).

Post reply on HN