3 ms·

I very rarely check the repository history, even less to find an answer in how some buggy behavior was introduced. At most I'll git blame, search the issue rep

I very rarely check the repository history, even less to find an answer in how some buggy behavior was introduced. At most I'll git blame, search the issue repository and see if I can chat with the concerned people. Understanding the current relevant code and what need to be done is basically always sufficient to do the job. Digging into history, while potentially very interesting, never helped to reduce the time to resolve anything in my experience. If the code is a mess, the history will be exponentially so. If the code base is clean and well documented, you might more likely have a great set of "perfect commits" that you will never need.

deleted 4y ago
[deleted]
quickthrower2 4y ago
History is useful because blame often get’s it wrong. So it is a manual blame.
grogers 4y ago
Writing good code and writing good commits definitely clusters together. It's part of a general pride in quality of work, organization, and planning. Going back into the commit history can be useful to figure out if something suspicious was introduced intentionally or if it was just a mistake. Beyond about 3-6 months, the author will generally not have any context to remember small code details, so leaving breadcrumbs for your future self and team can be nice.
js2 4y ago
> see if I can chat with the concerned people The concerned people quit and now I'm left supporting their untested, undocumented, unreviewed code that doesn't have commit messages more meaningful that "now it works", "fix it", "make it work", "another try". So now answering every "why?" question takes me much longer than if the damn code was just documented in the first place. I often go back to my own code, go to make a change, can't remember why I did it a particular way, run "git blame, git show" and thank myself for having the foresight a year ago to spent an extra minute or two when the code was fresh in my mind writing down why I did something a particular way. If that doesn't float your boat, fine, but I don't want to work with you. The git repo itself is the epitome of what I aim for in my commit messages. Here's an example: https://github.com/git/git/commit/d3775de0745c975e2d13819a630757b2bbb673c3 https://github.com/git/git/commit/d3775de0745c975e2d13819a63... Literally a single line change, the addition of: BASIC_CFLAGS += -O0 to the top level Makefile, and 9 paragraphs of explanation in the commit message.

deleted 4y ago

[deleted]

quickthrower2 4y ago

History is useful because blame often get’s it wrong. So it is a manual blame.

grogers 4y ago

Writing good code and writing good commits definitely clusters together. It's part of a general pride in quality of work, organization, and planning. Going back into the commit history can be useful to figure out if something suspicious was introduced intentionally or if it was just a mistake. Beyond about 3-6 months, the author will generally not have any context to remember small code details, so leaving breadcrumbs for your future self and team can be nice.

js2 4y ago

> see if I can chat with the concerned people The concerned people quit and now I'm left supporting their untested, undocumented, unreviewed code that doesn't have commit messages more meaningful that "now it works", "fix it", "make it work", "another try". So now answering every "why?" question takes me much longer than if the damn code was just documented in the first place. I often go back to my own code, go to make a change, can't remember why I did it a particular way, run "git blame, git show" and thank myself for having the foresight a year ago to spent an extra minute or two when the code was fresh in my mind writing down why I did something a particular way. If that doesn't float your boat, fine, but I don't want to work with you. The git repo itself is the epitome of what I aim for in my commit messages. Here's an example: https://github.com/git/git/commit/d3775de0745c975e2d13819a630757b2bbb673c3 https://github.com/git/git/commit/d3775de0745c975e2d13819a63... Literally a single line change, the addition of: BASIC_CFLAGS += -O0 to the top level Makefile, and 9 paragraphs of explanation in the commit message.