20 years of Git

My last CAD file was 40GiB, and that wasn't a large one.

The idea that all sources are text means that art is never a source, and that many engineering disciplines are excluded.

There's a reason Perforce dominates in games and automotive, and it's not because people love Perforce.

Wikipedia tells me the initial release of Subversion was in late 2000, and for git it was 2005 - but although those were kinda just smack in the middle of my first years online, learning to code, starting with FLOSS work, and so on - I think those years were pretty important with the shift to the WWW and then web 2.0.

I basically don't remember a world without SVN, but that's probably because I just missed the cutoff and projects and companies were migrating from CVS from 2002 on or so, because the model was very similar and while it wasn't drop in, it made sense.

For git I want to say it took just a little longer, and the decentralized model was so different that people were hesitant, and before github in 2009 (I know it was founded in 2008, but my user id is below 50000 and it felt very much new and not at all widespread in non-rails circles before that) I would have called it a bit niche, actually - so it's more like a 7year span. But of course I was living in my bubble of university, and working for 2 small companies and as a freelancer in that time. I think bigger FLOSS projects only started migrating in droves after 2010/2011. But of course my timeline could be just as wrong :D

For “backed by” read “initially written by”.

I don't particularly remember Linus making any push for git to be generally popular. While he was more than happy for other projects to use it and be his testing resource, his main concern was making something that matched his requirements for Linux maintenance. BitKeeper was tried and worked well¹, but there were significant licensing issues that caused heated discussion amongst some of the big kernel contributors (which boiled over into flame-wars more than once or twice), and those were getting worse rather than going away².

A key reason for Linus trying what he did with Git, rather than using one of the other open options that started around the same time or slightly before, was that branching and merging source trees as large as Linux could be rather inefficient in the others — this was important for the way Linux development was being managed.

Of course most other projects don't have the same needs as Linux, but git usually wasn't bad for them either and being used by the kernel's management did give it momentum from two directions: those working on the kernel also working on other projects and using it there too (spreading it out from within), and people further out thinking “well, if they use it, it must be worth trying (or trying first)” so it “won” some headspace by being the first DVCS people tried³, and they didn't try others like mercurial or fossil because git worked well (or well enough) so they just didn't get around to trying the others⁴ that would have worked just as well for them.

----

[1] Most people looking back seem to think/imply that BK was a flash in the pan, but Linus used it for a full couple of years.

[2] A significant problem that caused the separation, rather than it being because BK was technically deficient in some way for the Linux project, was people reverse engineering the protocol to get access to certain metadata that would otherwise have required using the paid version to see, which the BK owners were not at all happy about.

[3] So yes, human factors, but less directly related to one particular human that is Linus, more the project he was famous for.

[4] That sounds a lot more dismissive than I intended. Of course many did try multiple and found they preferred git, as well as those who did the same but went with one of the others because they were a better match for the needs of that person/project.

Initially it was jarring to not get a different working directory for each branch, but I soon got used to it. Working in the same directory for multiple branches means that untracked files stay around - can be helpful for things like IDE workspace configuration, which is specific to me and the project, but not the branch.

You can of course have multiple clones of the repository - even clones of clones - but pushing/pulling branches from one to another is a lot more work than just checking out a branch in a different worktree.

My general working practice now is to keep release versions in their own worktree, and using the default worktree (where the .git directory lives) for development on the main branch. That means I don't need to keep resyncing up my external dependencies (node_modules, for example) when switching between working on different releases. But I can see a good overview of my branches, and everything on the remote, from any worktree.