[a1studmuffin]

Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information in addition to the code itself.

IMHO revision history is just as valuable to a company as the code itself.

[bonestamp2]

> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se.

So true, we have this one senior developer who gets mad if someone's algorithm isn't as efficient as it could be (fair enough I suppose). But we can't get him to use commit messages that are more than 1-3 words and simply mention a word or three about the area of code that was changed. Years later, he also can't remember WHY he made those changes, so I'd much rather work with someone who writes inefficient algorithms that are easily improved at any time than commit comments that are forever useless.

What was changed is easily seen in the commit itself, why needs to be in the commit message.

[_diligenteng]

I wonder why is it so hard for people to right good commit messages. At my company I've actually tried trying talking in-person to people, even write a doc explaining the benefits and how to do it, pointing people to good resources like this one: https://chris.beams.io/posts/git-commit/

And still, I can't get people to do it. I find it so valuable to look at commit messages that are written, that explains the why behind the changes in the commit but can't get people to see the same value as I do. Any tips on that? Would be really appreciated. :)

[mandeepj]

"What was changed is easily seen in the commit itself, why needs to be in the commit message."

Commit message is like subject of an email. Is n't it faster to look at commit message, and get an idea about change rather than go through commit and understand it?

[JohnFen]

> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se.

Oh, so much this! The same applies to in-code comments. If your revision notes (or your code comments) are only telling me what I can plainly read in the code, then they're utterly pointless. Tell me what I can't read in the code: the "why"s, as well as potential consequences and "gotchas" the changes may present.

[bentcorner]

> I'm in AAA gamedev and the codebase I deal with goes back 20+ years.

I'm curious what parts you work on (engine/tooling?). I've always had the impression that games usually have more throwaway code than other types of applications.

[justsid]

Until the OP mentioned Perforce, I was 100% sure they were a co-worker of mine. I also work on a 20+ year old project, mainly on the core graphics/game engine. It’s mainly used to power a single game franchise, although I’d say that any commits from more than 2 major versions ago aren’t all that useful anymore. Too many things keep changing especially around the area that I work on.

[Sharlin]

Well, the Unreal Engine is 22 years old. I doubt the current incarnation is free of legacy code.

[t-writescode]

Could easily be a sports game. That was my guess, then I remembered that the quake engine powered Half Life 1 forever. Could possibly also be working with the iD engine?

[sillysaurusx]

How's the AAA industry nowadays? I got out awhile ago (though HoN never really counted as AAA) but it was a fun ride at the time.

Is work life balance a bit better now, or does everyone still push themselves pretty hard?

[dijit]

It's both better and worse than its ever been.

There's an awareness and discussion about "sustainable" development practices, but a large portion of our workforce had to leave for stress reasons last year, on a project that is saying "sustainable development" the loudest.. so while it feels like lip service, at least there's an awareness at some level.

(also, gamers are more entitled than ever, so we're always running; which causes our games to be buggy as hell which slows us down later.. horrible and completely unsustainable)

[personjerry]

But that sounds like you value documentation, not necessarily the code history

[sanderjd]

Code history is documentation. There are lots of different kinds of documentation: code API level, module level, system level, tutorials, even books in some cases. Revision history is just another one of those levels, and I believe it is the best at capturing the "why"s of systems rather than just the "what"s.

[lincolnq]

This is a great comment, except for the last line, which is extreme hyperbole.

[dillonmckay]

Parent clearly stated it as opinion.

[dang]

Isn't it a tautology? Revision history includes the code itself.