4 ms·

I'd second that. I've also used old revisions to try and figure out when a particular bug I've found was introduced too. Depending on how long it's been there

by onei 7y ago

I'd second that. I've also used old revisions to try and figure out when a particular bug I've found was introduced too. Depending on how long it's been there can help you assign a priority, e.g. minor bug has existed for 10 years without anyone noticing is probably not something you have to fix right now. The opposite of that is a nasty bug has existed for 10 years until some data structures or control flow changed and exposed it, so it's not a hard and fast rule. Once or twice I've seen bugs be introduced by merging huge commits from another branch, so there's lessons to be learned from history too. In this case, avoid large merges with conflicts, especially something you cherry-picked.

hinkley 7y ago
First git project, had a guy who loved deflecting, hated git, and had a habit of fucking up merges. Let’s call him Steve. Some code got broken and Steve immediately throws Jim under the bus. I look at the commit history, and sure enough git blame shows Jim broke it. Except... there was one little problem: I was the one who signed off on that code. I was specifically looking for this exact class of bug before I approved it, and was pleasantly surprised to see that the author had already anticipated this problem. So what the hell happened? Steve happened. Steve fucked up (another) three way merge and I didn’t catch it this time. I found the original commit hash and sure enough the code was correct. So then I showed Steve, again, what I call a Five Way Merge (3 way merge, then resolve again against both parents) and made it pretty clear this was no longer a strong suggestion and now a demand that he use this method to do merges.