Ah, good to know that that exists. Since you mention not needing to resort to that very often, is that because the applications you work with have a fairly low bug count, or that the PRs are long-lived enough, or that the code flows (and as such, developer intent) always sufficiently clear? I just ask because I shiver at the thought of all the extra time that I would have spent fixing bugs without the context of a detailed commit history.
That's a good question. I think part of it is low regression bug count. Also the code is usually clear enough that tracking down the code is pretty easy.
That would indeed make a big difference. The code that I'm used to working with tends to have complex flows (not in a spaghetti way, it just needs to do a lot), with fairly large amount of business-related decisions (i.e. 'what' and 'how' are insufficient, you need 'why' as well).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ah, good to know that that exists. Since you mention not needing to resort to that very often, is that because the applications you work with have a fairly low bug count, or that the PRs are long-lived enough, or that the code flows (and as such, developer intent) always sufficiently clear? I just ask because I shiver at the thought of all the extra time that I would have spent fixing bugs without the context of a detailed commit history.
That's a good question. I think part of it is low regression bug count. Also the code is usually clear enough that tracking down the code is pretty easy.
That would indeed make a big difference. The code that I'm used to working with tends to have complex flows (not in a spaghetti way, it just needs to do a lot), with fairly large amount of business-related decisions (i.e. 'what' and 'how' are insufficient, you need 'why' as well).