@agressivelyPassive @technom Thatâs a self-fulfilling prophecy, IMO. Well-structured commit histories with clear descriptions can be a godsend for spelunking through old code and trying to work out why a change was made. That is the actual point, after all - the Linux kernel project, which is what git was originally built to manage, is fastidious about this. Most projects donât need that level of hygiene, but they can still benefit from taking lessons from it.
To that end, sure, git can be arcane at the best of times and a lot of the tools arenât strictly necessary, but theyâre very useful for managing that history.
Iâd still argue, that the overhead is not worth it most of the time.
Linux is one of the largest single pieces of software in existence, of course it has different needs than the standard business crap the vast majority of us develop.
To keep your analogy: not every room is an operating room, you might have some theoretical advantages from keeping your kitchen as clean as an OR, but itâs probably not worth the hassle.
To keep your analogy, most peopleâs git histories, when using a merge-based workflow, is the equivalent of never cleaning the kitchen, ever.
No, itâs not. And you know that.
Seriously, ask yourself, how often did the need arise to look into old commits and if it did, wasnât the underlying issue caused by the processes around it? Iâve been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back. And I spend maybe 10min per year on that on average, if at all.
I honestly donât see a use case that would justify the overhead. Itâs always just âbut what if X, then youâd save hours!â But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.
