I loved the AOSA books, but there's been sometime that they don't publish a new one.
Do anybody know if there is something new in the works?
And of any other similar books?
The Architecture of Git (2012)
41–50 of 85 posts
Re: The Architecture of Git (2012)
#42Not sure if it’s of any relevance but I recently discovered https://gitup.co and must say, it’s pretty cool.
Fork (git-fork.com) is pretty neat as well
Re: The Architecture of Git (2012)
#43Earlier 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.
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'v…
I work in web development and Git has usually been good enough for our projects. But recently we have had a few projects that used large files and started using git-lfs in those. Is git-lfs not good enough for storing large assets in a git repository?
Speaking of non-coders using a VCS, our designers use Sketch (a macOS app) and until recently have used Dropbox for sharing and put the date into the file name as a form of version control. But they have now started using the Abstract app (https://www.goabstract.com/) which is a fancy UI around git (I think, not sure though), but none of that VCS complexity is leaking through. And they seem to like it. So maybe all it takes is a custom GUI that's tailored for a narrow and specific use case.
Re: The Architecture of Git (2012)
#44I'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.
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.
Re: The Architecture of Git (2012)
#45"The Architecture of Open Source Applications" is great. I highly recommend their other articles, as they are all interesting and informative. If you can, throw a few bucks their way by buying the PDF or paperback versions.
Re: The Architecture of Git (2012)
#46The 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 thes…
> Ah, ha ha ha ha ha ha ha ha ha ha ha
Would you please not post like that here? It degrades discussion.
The rest of your comment is ok, though the reader would learn more if you explained what the problem actually is.
Re: The Architecture of Git (2012)
#47The 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...
I've always liked the low-level explanation at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
It's a great exercise for the reader to recreate the core functionality of making git commits with just a few command line utilities (echo, wc, xxd, shasum).
Re: The Architecture of Git (2012)
#48Git is the VCS most suitable for bottom-up learners. Which is the VCS most suitable for top-down learners?
What are top-down and bottom-up learners?
Re: The Architecture of Git (2012)
#49The 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...
I've always liked the low-level explanation at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It's a great exercise for the reader to recreate the core functionality of making git commits with just a few command line utilities (echo, wc, xxd, shasum).
IIRC,that's how they were implemented in the first place.
Re: The Architecture of Git (2012)
#50Earlier 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.
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'v…
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 people's changes is something that can be clearly defined and executed. When it comes to assets, there is no clear definition of whether and how you can merge changes. It's not even clear for which kinds of assets diff and merge are concepts that make sense.
There's a lot of work that could be done there, but it doesn't seem like it will be done any time soon, mostly because game development is one of the most single-minded fields in software development industry; the only thing that matters is momentum and meeting the deadlines at all costs (witness the latest Rockstar Games controversy about 100-hour weeks) and everything else is secondary.