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

51–60 of 85 posts

Re: The Architecture of Git (2012)

#51

Post by pfranz »

CodeMage wrote: post #50
pfranz wrote: post #37

Earlier quoted context omitted.

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…

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 police and gives you a clear straight-line history (anyone who has used it is also aware of the downsides). Git's permissive system where you can make changes, but then you have to resolve them before committing shifts around the problem. This seems to be more of a problem for them? Maybe because they're more medium-sized and have more of a flat hierarchy?

I was going to bring up Unreal Engine. It has had Perforce integration for awhile and Git integration has been in beta (I wouldnt be surprised if that has changed in the last few years). It abstracts everything into the engine UI (so no things like branching). It performed way worse. Their docs have a lot more caveats.

https://wiki.unrealengine.com/Unreal_Project_Git_Workflow_(T... https://wiki.unrealengine.com/Git_source_control_(Tutorial)

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

Re: The Architecture of Git (2012)

#52

Post by crispyambulance »

pfranz wrote: post #37
crispyambulance wrote: post #19

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.

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…

    > unreasonable to expect the same tool for everything
Git is not the end of the road for vcs.

While I am sure that there are scenarios where other tools are better-suited, question I was responding to wasn't signaling any of those relatively edge-case scenarios (like binary assets in games).

The sad truth is git has now utterly dominates version control in such a way that you pretty much have to master it to be able to work in a team of developers because, most likely, they are using git.

Whatever the case, few of us get to choose what vcs we get to use. So if it is not git, it is perforce, subversion, or something else or even nothing.

"Just adapt" is what I should have said first.

Re: The Architecture of Git (2012)

#53

Post by sfescape »

erwan wrote: post #36
sfescape wrote: post #30

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 land…

I said one of the most. I didn't declare it the most...

Re: The Architecture of Git (2012)

#54

Post by rbonvall »

sfescape wrote: post #30

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.

This is from 2012, so it makes more sense to be surprised that it doesn't mention git being a crowdfunded, gamified, phablet-compatible cybertool as-a-service on the cloud.

Re: The Architecture of Git (2012)

#55

Post by sfescape »

ysleepy wrote: post #44
sfescape wrote: post #30

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.

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.

Re: The Architecture of Git (2012)

#56

Post by sfescape »

beagle3 wrote: post #34
sfescape wrote: post #30

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.

It was written before “blockchain” was a well known term.

git predates the creation of bitcoin and 13 years after the invention of blockchain.

Re: The Architecture of Git (2012)

#57

Post by sfescape »

rbonvall wrote: post #54
sfescape wrote: post #30

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.

This is from 2012, so it makes more sense to be surprised that it doesn't mention git being a crowdfunded, gamified, phablet-compatible cybertool as-a-service on the cloud.

lol

Re: The Architecture of Git (2012)

#58

Post by pfranz »

wereHamster wrote: post #43
pfranz wrote: post #37

Earlier quoted context omitted.

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 for…

On those web projects, is Git used just for versioning the delivered assets (psd, jpg, and gifs) or is it used for the working files (Illustrator, Photoshop, etc)? I've used it for the former, which is why I said it was more manageable, but not a great solution. If you were to treat it like we do code, you'd only commit the working files and have a build script to generate the deliverables.

Those are tooling problems, but I also think there are architectural problems. I don't have a lot of experience, but I have looked at git-lfs. You need a separate repo and also a separate path for data, right? It's also an add-on. It's all working around Git itself. For artists, what's the value add over Perforce or SVN? I can see that maybe you could use the same tools as the coders, but you have a bunch of new problems. I'm not saying it doens't have its place. I can see myself using it in the future, it just doesn't look like an out of the box solution.

A few years ago I was toying with something that would be more like how a lot of backup systems work (and I think macOS attempted something like this a few years ago and abandoned it). Each time you save it will make an auto-commit, if your app has integration, it takes a screen shot and stores any metadata from the scene (this was targeting a 3d application, but with the goal of also working with the filesystem directly). You could also make an explicit commit and give a commit message. Auto-commits would get flattened into hourly, daily, weekly. Explicit commits would stay around as indefinitely as you'd want. Git was a poor backend for this because I don't think you can merge commits in the background, that also rewrites history. This was focusing on version control for an individual, ignoring collaboration and merging.

The whole reason Git was written is because the data-structures facilitate the needs of the Linux kernel's programmers more cleanly (“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”) I feel like a lot of these Git tools for artists are coercing Git's data structures into an awkward workflow. That's the biggest reason why I hope it's no the end of the road for VCS.

Thanks for introducing me to Abstract. I know I've seen similar attempts in the past. I hope it's useful to artists and I hope Abstract is a successful business, but I'm a bit bummed that Open Source is relegated to a sub-group of programming.

Re: The Architecture of Git (2012)

#60

Post by elcomet »

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.

But when was the term 'blockchain' used for the first time?

This is just a matter of definition. You can call git blockchain or not, the only fact is that git shares the merkle tree property with Bitcoin.

Post reply on HN