4 ms·

Perfect commits are a bulwark against technical debt: https://www.infoq.com/articles/business-impact-code-quality/ https://www.infoq.com/articles/business-impa

• psychoslave 4y ago
  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.
• mianos 4y ago
  Is this irony? Given the time.to write the odd comment, tidy a bit of code write a commit message, I know what I ask for. People read the code. I am sure some people jump right to the commit log but I have never met one in my 40 years as an active developer. Commit messages matter. A short statement of intent is a good idea. Dangerfiles are the penultimate expression of bikeshedding.
• keyle 4y ago
  Until the requirements change 12 times over 12 months, and that time invested writing prose with all the stuff that goes with it goes down the drain. Don't get me wrong, I'm not saying commit crap. I'm saying "Yes But". Use code as documentation, use Tests as defence turrets, forget the poetic muppetry. The code should reflect the now and mark the pitfalls. If the code is well written, I should be able to understand the why it's done this way. Don't send me off to some document on confluence written by the dude that left 2 years ago.
  • simonw 4y ago
    That is the exact argument I'm making this article: if your documentation is on confluence it will inevitably go out of date. The solution to that is to keep the documentation in the same repository of the code, and update it in lock step every time you make an implementation change that affects the documentation.
• wruza 4y ago
  For a counter example, most of my work projects usually live up to 3-4 years (with 0.5-1 year of iterative development) and I have never investigated a commit from the past nor had to understand what it does, because that state of a project has nothing to do with today’s and checking it out or blaming is usually completely meaningless, unless it’s from the last week or two. I believe that most of these high-culture commit advices come from a specific (maybe common in bigcorps maintenance phase, idk) development process and/or paradigm, which may or may not be present at your workplace (though you may pretend they are, as we all do sometimes to look better). Personally and company-wise we are using RCSs simply to merge parallel work and to have an undo stack a little deeper than an editor could provide. That’s it. Nobody ever goes to the history, unless there is a technical issue with RCS itself. I’m not suggesting to write “new task” in a commit message, but am not fond of writing markdown poems there either, or committing every 3 minutes because changes “must” be short. Commit when it’s done, for some reasonable definition of “it” and “done”, and explain it in one line in under a minute, this is my empirical rule. If you have more to tell, tell it in the comments. (That’s what your future self will really be grateful for.) Pretty sure that many people who nod to all this noble culture actually silently relate more to the above. Edit: should have read this subthread before being cautious in my statements. Glad that there are people who share these views. Because reading on how to do it The Right Way and then waiting for “the obvious benefit” over decades may be confusing and anxiety inducing af.
  • js2 4y ago
    You've presented a strawman argument. No one is suggesting committing every 3 minutes, nor writing markdown poems. Commit your work in logical blocks that make sense and explain what the change is doing and why so that a developer other than yourself can understand why the change was made. That's all. Unless you expect 100% code churn, you'd be surprised what really survives in the history. And even in the course of churning code, I often refer back to commit messages for the existing code. As I've mentioned elsewhere, I've been doing this a long time (more than two decades) at startups and fortune 500s, on both open and closed source code, on projects of all sizes. I'm surprised frankly that 3-4 years on a single code base has not been enough time for you to have never wished you'd written a better commit message. I literally lost an hour today working backwards from an error message to what the code was actually complaining about. No comments in the code. No documentation on the API endpoint. No commit message or PR description to explain the change beyond "make it work now with IPA uploads." In my experience, all these things go together and are signs of a conscientious developer. The code tells the computer what to do. The commit message tells other developers what the code is supposed to do and why it's supposed to do it. This has nothing to do with nobility. It's about sustainable development that tries to avoid technical debt, about being forward thinking, and about courtesy to future maintainers of the code you've written. Someday that future maintainer may be you.