From mboxrd@z Thu Jan 1 00:00:00 1970 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 18 Dec 2020 12:41:58 -0500 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201218144332.GH13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> <20201218144332.GH13368@mcvoy.com> Message-ID: On Fri, Dec 18, 2020 at 06:43:32AM -0800, Larry McVoy wrote: > Source management to the rescue. I hired an extremely smart guy (he > reads papers on string theory, the physics ones, for fun). Taught him > how to use our tools. Gave him a bug to fix. He looks at the source > file and goes "This is crap, I'm gonna rewrite it so it is clean". > Then remembers I showed him how he could see how the file evolved. > So he looks at the first version of the file. It is *exactly* what he > was going to write. Huh. He starts going through the history. Oh, > this wart is for IRIX. This wart is for windows 2000 that reuses PIDs > right away. This wart is for NFS. Etc. > > In the end, he added another wart to fix the bug and left the file alone. > I did say he was smart. ....and this is why when I do code reviews, I'm asking for improvements in the commit (or CL) description at least as much as I am pointing out issues in the code itself. In some cases, when the contributor is someone for whom English is not their first language, I'll end up rewriting the commit description as well. Code archeology is *definitely* a powerful tool, but this relies on the source control metadata is sufficiently rich; in some cases, having links to bug trackers or mailing list discussions are super-useful. - Ted