My Favourite Git Commit

Post by Bartweiss » Fri, Oct 18, 2019, 4:29 PM UTC

SamBam wrote: post #200

0zymandiass wrote: post #88

Earlier quoted context omitted.

To me, at least, the issue with that commit message is the signal-to-noise ratio. There is a lot of exposition for each piece of information. I prefer a more declarative commit message. However, from the writing, I suspect this is just due to the committer not being a native English speaker. e.g. the first paragraph doesn't lose any important information trimming it down to: "After adding a test matching the contents…

Hmmm, I've always believed that no commit should break a build, even if you're committing the fix right after. Otherwise you're going to cause problems for `git bisect` or other practices of going through the history to find where a problem may have started. Do other people commit breaking tests and then fixes?

Post by YourMatt » Fri, Oct 18, 2019, 4:35 PM UTC

jmilloy wrote: post #197

jordigh wrote: post #168

Earlier quoted context omitted.

> I don't want your entire life story in my commit log. Why not? Where else do you want it? Is something forcing you to read the full commit log? There's no length limit on commit messages and commit messages are mostly out of the way. Most VCSes have a way to only show you the first line. So if you want summaries, that's what the first line is for. If you want the full story, that's what the body is for. Combined wi…

I think the problem isn't the length or content of the commit message, but its organization. It needs to have the most important information first. It reads as an "entire life story" because it is written in a narrative, sequential form. Better organization would make it skimmable, and later coders could only read as far as they need to.

Post by hermitdev » Fri, Oct 18, 2019, 4:37 PM UTC

btilly wrote: post #243

beefhash wrote: post #101

I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

Oh. Locales. The remembered pain. Save a file in Notepad. Open in vi. See that it is different. Find data in the database, no clue the weird characters were originally supposed to be. And so on and so forth. I once wrote a reasonable program and sent it as a bug report to the maintainer of the Perl module DBD::File. He sent it as a bug report to BerkeleyDB. They said they never thought about it but yes, that would be…

    def _wrap_str(value: str):
        try:
            return SqlVarChar(
                value.encode("cp1252")
            )
        except UnicodeEncodeError:
            logging.getLogger("bulk copy").exception(f"value causing error: {value}")
            raise

Post by ericmcer » Fri, Oct 18, 2019, 4:39 PM UTC

laurent123456 wrote: post #96

robin_reala wrote: post #53

Earlier quoted context omitted.

…or fix the non-Unicode compatible systems that are consuming the commit messages and breaking? If they fail with an nbsp then they’re probably also going to fail with more obviously useful non-ASCII characters.

How often are non-breaking spaces purposely inserted vs accidentally? And the tools might handle them fine but will produce strange results or errors. An example is inserting a non-breaking space in a document or string. It will prevent word wrap, which might not have been the user intent. A linter that requires these spaces to be explicitly set in encoded form would avoid these issues.

Post by luhn » Fri, Oct 18, 2019, 4:41 PM UTC

deaps wrote: post #95

This gives me ideas. My commits are usually short and sweet - to the point. I document my code very well, however. One of my strengths in a previous life as a Master Automobile Technician was the ability to document the entire process -- from duplication of a concern, to troubleshooting, to correction, to verification...it's literally how I got paid (which I never understood why so many automotive techs took short cu…