[userbinator]

moving changes from Windows 95 to Windows NT involved manually doing three-way merges for all of the files that changed since the last drop. I suspect that this manual process was largely automated, but it was not as simple as a git merge.

The first release of git was in 2005, around a decade after Windows 95.

[Someone]

You don’t need git to get something “as simple as a git merge” (Diff3 is from 1979 (https://en.wikipedia.org/wiki/Diff3)

Diff3 is from 1979 (https://en.wikipedia.org/wiki/Diff3), so three-way merges (https://en.wikipedia.org/wiki/Merge_(version_control)#Three-...) predate git by decades.

[sho_hn]

Wow! I am stunned how wrong that feels. I remember adopting git in the first year, and it still feels fairly recent. That it only took 10 years from Win95 to git, and 20 years from git to now, is truly uncanny. Win95 feels like a genuinely old thing and git like a fairly recent thing.

[AlecSchueler]

Time started moving faster after smartphones began to steal our reflective moments.

[darkwater]

I don't know how old are you bit if you are in your 40s it's s just because you were a kid when Win95 came out and time seems longer when you are a kid (less routine, everything new, more attention all the time etc)

[sho_hn]

Probably a mix of this, and also that it feels like there have been many strikingly different milestones for Windows as a product since Win95, while git is not fundamentally different since 2006/07, or at least change has been far more gradual. Windows is so storied it feels older.

[torben-friis]

There’s been two main massive shifts that create before-and-after feelings in tech. One is going from “the computer is that super-typewriter that can send mail” to internet culture, and the second is going from online in pcs to always online in smartphones.

Win 95 feels from era1, xp and git was already in era 2.

Once those two changes were done by 2010 though, there’s been no game changer, if anything we've regressed through shittyfication (we seem to have fewer social networks vs the original Facebook for example, as most of them turned single player feed consumption).

Maybe pre and post LLMs will feel like an era change in a decade as well?

[keyle]

Three way merges were a thing before 2005... The author was merely comparing with today's tools.

[iso1631]

I wonder what percentage of people on HN have ever used subversion or cvs, let alone older systems.

[keyle]

I remember the days of NT4 and the guy that would lock a file, leave for the day and you couldn't check it out :D Good times!

Same year I deleted all our customer's websites by simply dragging the hosting folder somewhere into C:\programs or something by mistake... A double click + lag turned into a drag and drop! Whoops!

I was pale as a ghost as I asked for the zip drive.

We had to reboot the file server first, which we did a swift kick to the power button.

At least today we employ very secure mechanisms; like YAML rollouts of config, to keep things interesting.

[Thorrez]

CVS was released in 1990. Subversion was released in 2000.

Google still uses a clone of Perforce internally (and various wrappers of it). Perforce was released in 1995.

[ACS_Solver]

Perforce is standard in gamedev currently. As a programmer first and foremost, I prefer git but I've certainly come to appreciate the advantages of Perforce and it's an overall better fit for (bigger) game projects.

[butlike]

Does it do better handling of larger files, like game assets?

[ACS_Solver]

Yes, Perforce handles large files, and large folders of files, very well. It's quite efficient with deltas in binary files. It's also very useful that Perforce expects clients to check out only a part of the depot. There are folders with raw assets like uncompressed sound, layered graphics and all that, I don't check out any of that, I only check out the necessary in-engine assets.

For code, I prefer git as I said, but in a game's depot most files are not code, and Perforce is built around handling those other assets well.

[pseudalopex]

Yes. And other game development tools integrate Perforce better than Git. File level security is another advantage.

[grujicd]

I'm still using subversion as it servers solo developer needs perfectly.

[dotancohen]

Only if you don't branch often. The way I code, I branch for every feature or bugfix. Even on my personal projects.

[iso1631]

If you're just doing an edit on main and push changes, git can do that fine just as well as svn, but no need to run a specific server on your laptop either, and in a client/server basis back to your home pi you just use standard ssh rather than running a special server.

[bregma]

I remember moving from SCCS to RCS because it was considered superior.

[cbm-vic-20]

I work on a project that we started in CVS, then moved to Perforce, and now on git. With full, intact history.

[genezeta]

sccs, I was using it as late as the 90s.

But the percentage is probably small, yes.

[sys_64738]

Sun used SCCS until they moved to Mercurial in the early 2000s.

[HeinzStuckeIt]

Funny how fast Git became entrenched as the way of doing things, though. Around 2010 I said in passing, in a forum discussion about how a FOSS project was getting along, “…you’d think someone could send in a patch…”, and I immediately got flamed by several people because no one used patches any more.

[Someone1234]

> Funny how fast Git became entrenched as the way of doing things, though.

It just really highlights how much better BitKeeper and then Git's design was compared to what came before. You then pile on being free/OSS, and being "proven" by an extremely large, well known, and successful project on top, and you have yourself explosive growth.

There are developers around these days who never had the displeasure of using the pre-Git source control offerings; it was rough.

[raverbashing]

Funnily enough the Linux Kernel still use patches (and of course Git has helpers to create and import patches)

[chris_wot]

Don’t they get emailed patch from git? Sorry if I’m super ignorant here, it’s interesting to me if they do!

[st_goliath]

You can use `git format-patch` to export a range of commits from your local git tree as a set of patches. You can then use `git send-email` to send that patch set out to the appropriate mailing list and maintainers (or just do it in one step, send-email accepts a similar commit range instead of patch files). It talks directly to an SMTP server you have configured in your `.gitconfig` and sends out e-mail.

Of course, `git send-email` has a plethora of options, e.g. you'd typically add a cover letter for a patch set.

Also, in the Linux kernel tree, there are some additional helper scripts that you might want to run first, like `checkpatch.pl` for some basic sanity checks and `get_maintainer.pl` that tells you the relevant maintainers for the code your patch set touches, so you can add them to `--cc`.

The patches are reviewed/discussed on the mailing list that you sent them to.

On the receiving side, as a maintainer, you'd use `git am` (apply mail) that can import the commits from a set of mbox files into your local git tree.

[thaumasiotes]

> Funny how fast Git became entrenched as the way of doing things, though.

> ...and I immediately got flamed by several people because no one used patches any more.

How are these ideas connected? The intent of git is that you work with patches.

[HeinzStuckeIt]

For most people, git is that you work with pull requests, and already early on some bristled at the term “patches” which implied an obsolete way of working.

[thaumasiotes]

> For most people, git is that you work with pull requests

Unlike patches, pull requests aren't even a feature of git.

[raverbashing]

As a comparison, CVS is from 1990, SVN from 2000 (and RCS from 82)

[agumonkey]

and even then, it's easy for merges to turn into chaos, git has no semantic awareness (no surprises here) and sometimes similar patterns will end up collapsed as a single change and conflict

[txdv]

maybe merging patch files was a thing way before git?

[kleiba]

> this manual process was largely automated

Priceless.