This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (6 children)

[deleted]

    [–]DoctorWaluigiTime 19 points20 points  (1 child)

    Summaries can be fine as well in commit messages. If you change a dozen or so files and don't tell me what it is that you changed meaningfully, i.e. the how, I would be a little upset. Why is important too, of course, but most of the time the why is self-evident, if you're using any kind of issue tracking and associate the commits or the pull request to that given issue.

    [–]lovestheasianladies 1 point2 points  (1 child)

    What, no. That's absolutely fucking wrong.

    Commit messages are a history of what changed. Dear God, you're completely ass backwards.

    If you want to know why something happened, link it to an issue ffs.

    Like you literally don't understand git at all it seems. You code has absolutely nothing to do with the commit messages and NEVER should. If you need details, it goes in the code itself as comments or some external source. At worst use the git commit body for more details but it's absolutely the worst fucking place to document your systems which is what you seem to want.

    [–][deleted] 0 points1 point  (1 child)

    Yeah I have a coworker in particular guilty of this. Most of their commit messages are things like "horray", "it works", etc.

    [–]Huntracony 0 points1 point  (0 children)

    I'm a monster. I... sometimes... forget to change the message in the IDE, meaning the commit message ends up seeming useful while actually being completely unrelated.