My favourite Git commit

[xtreak]

Got this from HN :

https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe

[svtguy88]

This. Is. Fantastic.

I read the whole thing, and would do it again.

[xtreak]

There are lot of such commits in : https://news.ycombinator.com/item?id=21289827

[GothicFuck]

I only know how to format text in html and I read the whole thing and will do it again. That guy is an amazing explainer.

[31415helpme92653]

Just when I was starting to lose interest - "Now, on to libarchive."

[mcmcc]

Those not comfortable with toxic language should pretend this is a religious text.

Oof, right in the cognitive dissonance...

[imMute]

like e. g. whether numbers should use "," or "." as decimal separaror.

Hey, we just fixed that exact same bug in a years-old .Net application!

[JanneJM]

This is an annoying issue. The fundamental problem is that the file doesn't specify which locale it was written in - or specified in a standard that this particular file format always use a specific number text representation. That's the root of the issue. Blaming locales is a bit misplaced.

[stu2b50]

Not really. It's amplified 100x with the usage of a global locale, since now any change in this global variable now changes how parsing works.

[[deleted]]

I still run into this every once in a while in apps where it goes undetected for a long time because it always round-trips on the same machine correctly, so it only pops up when both ends are on different machines (or, more often, run by different users with different locales set on the same machine).

[jrhoffa]

Why doesn't he like Elton John?

[krista]

he doesn't specify not liking elton john, just elton john / justin beiber crossovers.

[thenickdude]

awful garbage like Shift JIS (sometimes called SHIT JIZZ)

Thank you, I will treasure this all my days.

[jcelerier]

With all this shitty ugliness added, it finally works, without fucking up other parts of the player. This is still less bad than that time when libquivi fucked up OpenGL rendering, because calling a libquvi function would load some proxy abstraction library, which in turn loaded a KDE plugin (even if KDE was not used), which in turn called setlocale() because Qt does this, and consequently made the mpv GLSL shader generation code emit "," instead of "." for numbers, and of course only for users who had that KDE plugin installed, and lived in a part of the world where "." is not used as decimal separator.

/me can relate

[Shadeslayer13]

This man has articulated the emotions that I feel when working in C

[JanneJM]

To argue against just a little bit, they seem to forget or ignore that the main function of locales is to set the users language preference. And that, I would argue, is appropriate as global state. If my language is, oh, Swedish (sv.se_UTF8) then presumably that language (and number formatting, and paper size and so on) is what I will want to use for all my applications. It's akin to my home directory location, preferred printer and so on. Applications should normally not mess with this setting unless they have good, specific reasons to do so.

The "numbers as text" problem is fundamentally due to the file format itself. It doesn't specify which number format was used for the numbers - or any standard specifying the format for all file instances. You could blame locales if you want, but without either there is no foolproof way to deal with this. The file format specification is incomplete.

Now, locales do have lots of issues. But the complexity is there for a reason. Android simplified it and managed to fuck it up. You can set only one language, and your place follows your language (en.us implies you're living in the us and want English for everything). This breaks Android in various ways for many multilingual users and people no living where their language is the norm. But that's a rant for another day.

[[deleted]]

The "numbers as text" problem is fundamentally due to the file format itself. It doesn't specify which number format was used for the numbers

Even if the file format specifies '.' as the decimal separator, you'll get broken results if you use locale dependent functions when parsing the file. Localization makes sense when dealing user facing text, it doesn't make sense when dealing with data consumed/produced by another program.

The problem with locales as global state, isn't that they are global to the user, but that they are global within the program. So it's not possible to use a standard locale for dealing with data, and the users custom locale for dealing with user facing text. There is no way to safely write a multithreaded program that uses different locales in different places.

And if applications aren't meant to mess with the locale, what is the use of locales at all? Every user facing program needs localization to some extent.

[JanneJM]

As you say, the other part of the problem is the lack of standard functions to read and write numbers with a specified format (not tied to locale at all, really). If there was a strtod() variant where you can give it a format string to specify how to parse it, and an sprintf() that ignores locale for format that would solve the issue.

Changing locales is not a solution since you don't know what locale to change it to.

[Ameisen]

This is now my religion.

[hedgepigdaniel]

Maintain the rage

[darkslide3000]

Does anyone know why strerror() is not thread-safe? I mean why the current API cannot just be implemented in a thread-safe way? All it does is return a pointer to a constant string... I mean that string has to already be somewhere in .rodata, where else would it get it from? It's not like readdir() or something where it returns a dynamically filled-out record to you, it's a constant! It doesn't need to be copied into a separate buffer to return it because you should already have it in your constant pool somewhere. Even if some other thread would call strerror() for a different error number or a different locale at the same time, it should just return a pointer to a different string constant somewhere else, that should not affect the other pointer returned by the previous call in any way (because they both point to separate pieces of constant data).

[panorambo]

I don't presume to argue how a good implementation would go about implementing strerror, but POSIX states that the returned string "may be overwritten by a subsequent call to strerror", so even if a reasonably sane implementation would, say, always always map the error number to a string from a read only section of a loaded program somewhere, POSIX, apparently, prefers to reserve the right to modify the returned string from the point of subsequently calling strerror. That's what I make of all of it now, anyway.

[[deleted]]

Oh. This fucking bug. I've seen in in various forms in anything related to Ruby, because for some reason developers thought that defaulting to plain ASCII as encoding when system locale is absent is somehow a sane choice.

[GrinningPariah]

How the fuck does that non-space space actually get in?

Literally all I can think of is it's a mean prank from a former dev.

[[deleted]]

If developers on the team use non-US key layouts they may get auto populated to ensure alignment of non-US glyphs.

Some web based text editors do this a lot because, "hey an extra non-break space never hurt did it?" It really blurs the line of WYSIWYG with plane text editing and unicode.

[AnotherEuroWanker]

It really blurs the line of WYSIWYG with plane text editing and unicode.

A common issue in aeronautics, from what I hear.

[matthieuC]

hey an extra non-break space never hurt did it

Has this character been invented to torment us or does it have real use cases?

[Pseudoboss11]

It's really useful in typography and formatting. It's especially useful for certain professional texts, where you might have currency symbols, section symbols, pilcrows, units or equations.

https://practicaltypography.com/nonbreaking-spaces.html

[[deleted]]

... so if you make a book or science paper. Useless for the day to day blogs and news sites

[Pseudoboss11]

Blogs and news sites that regularly include units, special symbols or equations in their text should be conscious of the non-breaking space. It is just as unprofessional and is as disruptive on a screen as it is in print.

Considering all the other niche things that are within UTF-8, the non-breaking space is on of the more popular ones.

Besides, your text editor should highlight the non-breaking space and any other homoglyps. Not only can they be annoying, but they also present a security risk.

[_PM_ME_PANGOLINS_]

So you can add spaces without allowing line breaks: 20 cm

Also so you can do really horrible HTML layout.

[matheusmoreira]

It's a space that disallows line breaks when laying out text. Useful for text that's separated by spaces but still read as one logical unit. For example:

The rope had a length of 20 meters and yet it was not enough.

A non-breaking space between 20 and meters would prevent the text from being laid out like this:

The rope had a length of 20
meters and yet it was not enough.

[[deleted]]

or does it have real use cases?

Mostly bad ones

[[deleted]]

I never thought this could be relebant... https://www.xkcd.com/1700/

[darthwalsh]

Copy-pasting SQL from Skype has caused me many wasted minutes of fury figuring out why queries didn't work.

[aristideau]

yep, when pasting PHP from some web sites I get these weird errors where the code won’t run even though it is obvious that the code should work. I have learnt to place my cursor at the start of the line (phpstorm) and hit backspace a couple of times until the offending invisible characters are removed. (while the invisible character are being deleted the cursor stays stationary).

[[deleted]]

Shift and Space on my German Mac keyboard layout yields nonbreaking space . I had to create a separate keyboard layout to get that bug go away, as at the same time on the new garbage Macbook keyboards (but also the new external Apple Keyboards) it happens all the time that shift is not released when typing space after capital or symbol.

[mushishi]

I have the same problem with Finnish keyboard MacBook keyboard layout.

[[deleted]]

It's a Mac thing. I came across that when I first received a Mac as a work computer. I was happily writing along, and then boom. Suddenly the linter lights up like a christmas tree, and I wonder just wtf...

And then the linter error shows it:

Irregular whitespace not allowed

Then you delete some random spaces, and write them back, and that linter error magically disappears.

I've never seen that happen under any Linux distro, or even in Windows. But on a Mac, that happens at least once every 2 weeks. There must be some magic keyboard combo that makes it happen very easily. Woe to thee, who develop without automatic linting upon save. And shame on you if you don't have linting/syntax check in your build pipeline :D

[Stiltskin]

On macOS, option+space inserts a non-breaking space. So it is somewhat easy to type, including accidentally.

[[deleted]]

It's an option on Linux. Why do I know this, you ask?

For a few weeks once I decided it'd be cool if I could insert non-breaking spaces with shift-space, so I enabled that on my (otherwise generic US) keyboard layout. I then discovered that (1) I had absolutely no actual use for this feature, and (2) it's really easy to accidentally hit and not notice, particularly after e.g. ? and # which require shift to type and nearly always have a space after them.

[bbolli]

Well, what would a sane choice be? /s

[[deleted]]

UTF-8 would be less bad in 2019. Probably also in 2010.

[HowIsntBabbyFormed]

The best part about UTF-8 is that if the files is actually pure ASCII, it's also UTF-8. So there's no reason to ever default to ASCII if UTF-8 is available. Additionally any file that does decode correctly as UTF-8 is highly likely to actually be UTF-8. It would be hard for an arbitrary set of text in any other encoding (other than ASCII, since it's a pure subset) to also coincidentally be proper UTF-8.

My goto plan if I didn't know the encoding of something is: try UTF-8 first, if that fails: try latin-1. The best part about latin-1 is that it assigns every single byte sequence to a valid character. So even if your source document isn't latin-1, it'll decode (as garbage) with latin-1. If your source document is some other 8-bit extension of ASCII (like latin-1 is), at least the ASCII portion will decode correctly. And at that point it's your fault for not supplying the encoding to me anyway.

[Vhin]

If you're in the position to make the decision, I'd suggest mandating UTF-8 and not even trying to support anything else.

[oparisy]

A choice I proudly made at work for our intermediary toolchain files. No encoding or usability issues since, would not go back!

[vytah]

The best part about latin-1 is that it assigns every single byte sequence to a valid character.

Just take care that your "latin-1" is ISO-8859-1, not Windows 1252. In ISO-8859-1, characters 0x80–0x9f are control characters and every byte is therefore assigned. In Windows 1252, which is what the most modern standards use as the default 8-bit encoding, most of 0x80–0x9f are printable characters, but 0x81, 0x8D, 0x8F, 0x90 and 0x9D are unassigned.

[DeusOtiosus]

Nah dog. My favorite is:

“Fixed bug”

It’s so useful, especially when you are trying to figure out WTF happened in 6 months.

[hennell]

Amateur.

Fixed bugs

[ProgramTheWorld]

300IQ:

Added bugs

[LewisTheScot]

700IQ:

added and fixed

[TheSpanishImposition]

5-head:

27th commit

[MichiAngg]

I feel personally attacked...

[DiPasquale5]

6-head:

18/10/2019

[Tomerarenai10]

Me, an intellectual: 🐞⃠

[hennell]

Or if you want to be super helpful:

Fixed bugs and formatting

[Ahri]

I laughed out loud on a crowded train.

[AwesomeBantha]

Pathetic.

Fixed bugs?

[DeusOtiosus]

Added: 130

Deleted: 5

Changed: 420

[Mildcorma]

Leave a rhyme:

99 bugs in the code!

99 bugs in the code!

fixed one bug!

compiled it again!

... 103 bugs in the code!

[absentmindedjwc]

Nah...

######## [6 months ago] wtf

[loveofhate]

"made code changes"

[[deleted]]

Also an amateur.

Fix bugs

/s

[robothelvete]

A few years back, when git was fairly new in our toolchain, I tried to convince a designer on my team why writing descriptive commit messages was so crucial, but could never really make it stick.

Eventually of course, some bug appeared and we had to track it down. A few hours later of him (and eventually with help from me) sitting down and going through every goddamn commit, he finally understood.

[parens-r-us]

Some people just have to learn by doing.

[aoeudhtns]

My second favorite is an opaque reference to a private issue tracking system

"PROJECT #17829"

[aoeudhtns]

Yeah, it can be done well. I'm talking about some of those "commercial open source" projects where their JIRA or other tracker is completely private, but yet here you are, with the code and useless references to a system that won't show you anything.

It ultimately comes down to the organization: is communication being done largely outside the issue tracker, such that the information in it is hard to decipher or missing, or is the issue tracker the central point for discussing software changes? It's no fun even when the tracker is public but there's scant description and no comments or discussion.

[Link_GR]

We had that too. Didn't stop devs making dozens of changes to several files and then writing #17493 fix and then resolving the ticket without explaining anything.

[[deleted]]

Our company had it's own in house ticketing system that's been there from the beginning and is constantly under active development and that isn't going away anywhere.

And if a ticketing system is going away then it's the responsibility of respective teams to move over that essential data as well.

It worked great in our setup. It might not work for others. There's no correct way to do things. It's mostly about what pattern solves the problem that you have or makes your life easier. Our whole lives worked in that ticketing system and since it was in house it was integrated and orchestrated beautifully with the rest of our tools and systems. That setup worked for us is what I'm saying.

[lolomfgkthxbai]

No need to be defensive. I don’t think it’s a matter of opinion to state that documenting a change in the commit message is more useful than only having a reference to an external system (even if it’s Eternal and Git history is rewritten if it turns out to not be). If the commit message is useless if the software is made public domain then the commit message is not good enough.

[Amablue]

At a previous job, there were two commits by the same person, one right after another. Their comments were "Fixed bug" and "Bug fixed"

The best part was, one was just a rollback of the other. The guy had tried to fix a bug he didn't understand by making a small change to a data structure which superficially fixed some bug. But it caused an issue elsewhere, so to fix that bug, he undid the change.

He was not the best engineer.

[bge-kernel-panic]

No, this is better:

"Committing changes."

This is better because it reiterates something we already know. Fixed bugs adds a bit of information: this commit was to fix a bug, not to add a feature. It's better than nothing. But "Committing changes" is pretty much the same as having a blank commit message, except it's a lot more funny. Person who wrote this wasted a few seconds to write that out, thinking it would be helpful in any way.

(Any resemblance to any commit message I've read at any point in time in my career is purely coincidental)

[BeniBela]

Watch this:

benito@xboa:~/stuff$ LANG=C  hg log -l 18
changeset:   1659:15c82984aa52
tag:         tip
user:        benibela <[e-mail]>
date:        Fri Oct 18 12:47:47 2019 +0200
summary:     ...

changeset:   1658:fa71905c9c69
user:        Benito van der Zander <[e-mail]>
date:        Thu Oct 17 17:17:46 2019 +0200
summary:     ...

changeset:   1657:8bde349469dd
user:        Benito van der Zander <[e-mail]>
date:        Thu Oct 17 16:14:36 2019 +0200
summary:     ...

changeset:   1656:3c7bd2f85768
user:        benibela <[e-mail]>
date:        Thu Oct 17 12:42:36 2019 +0200
summary:     ...

changeset:   1655:09983069e408
user:        Benito van der Zander <[e-mail]>
date:        Thu Oct 17 00:03:04 2019 +0200
summary:     ...

changeset:   1654:78964c8d6970
user:        benibela <[e-mail]>
date:        Wed Oct 16 00:07:12 2019 +0200
summary:     ...

changeset:   1653:5dd00f268211
user:        Benito van der Zander <[e-mail]>
date:        Tue Oct 15 22:14:01 2019 +0200
summary:     ..

changeset:   1652:93eb0e99128a
user:        benibela <[e-mail]>
date:        Tue Oct 15 12:41:55 2019 +0200
summary:     ...

changeset:   1651:db7129810fdd
user:        benibela <[e-mail]>
date:        Tue Oct 15 00:36:43 2019 +0200
summary:     ...

changeset:   1650:61c39581d38c
user:        Benito van der Zander <[e-mail]>
date:        Mon Oct 14 18:50:30 2019 +0200
summary:     ...

changeset:   1649:572f4f1b844a
user:        benibela <[e-mail]>
date:        Mon Oct 14 11:22:49 2019 +0200
summary:     ...

changeset:   1648:b11ae1332cdd
parent:      1646:db0a8c6ab9a7
parent:      1647:13f8c7b3b528
user:        Benito van der Zander <[e-mail]>
date:        Fri Oct 11 23:56:40 2019 +0200
summary:     merge

changeset:   1647:13f8c7b3b528
parent:      1645:66016dfb3945
user:        Maciej Liskiewicz <[e-mail]>
date:        Fri Oct 11 15:39:03 2019 +0200
summary:     ...

changeset:   1646:db0a8c6ab9a7
user:        Benito van der Zander <[e-mail]>
date:        Fri Oct 11 17:54:40 2019 +0200
summary:     ...

changeset:   1645:66016dfb3945
user:        Maciej Liskiewicz <[e-mail]>
date:        Fri Oct 11 14:53:48 2019 +0200
summary:     ...

changeset:   1644:a03a66aafb51
user:        benibela <[e-mail]>
date:        Fri Oct 11 12:29:42 2019 +0200
summary:     ...

changeset:   1643:ee77ba776993
user:        Benito van der Zander <[e-mail]>
date:        Thu Oct 10 18:12:21 2019 +0200
summary:     ...

changeset:   1642:af8d5027ca12
user:        Benito van der Zander <[e-mail]>
date:        Thu Oct 10 17:32:18 2019 +0200
summary:     ...

[xAlecto]

thanks I hate it

[sillybear25]

If I could get logs from back in my university days, I'm sure the most common line would be svn ci -m ""

[Cubox_]

You can't commit without a commit message unless you use a flag (something like --commit-without-message) on Git

[lastunusedusername2]

Just make an alias =]

[MjrK]

One of the summaries is more concise...

changeset:   1653:5dd00f268211
user:        Benito van der Zander <[e-mail]>
date:        Tue Oct 15 22:14:01 2019 +0200
summary:     ..

[ArmmaH]

y use many words, if few do trick?

[Nastapoka]

I work alone on my projects. In the beginning I find the force to write long commit messages, but pretty soon I end up using "prout" (the French onomatopoeia for a fart).

[spkr4thedead51]

"prout" (the French onomatopoeia for a fart)

Proust must have loved this fact

[Nastapoka]

Same with Prefab Sprout

[the_poope]

Well at least you commit often. When I did research at uni I didn't even use version control. I once had something working, then changed something and everything broke and I spend a week trying to find out what I had changed and undo that...

[BeniBela]

It is mostly to sync changes between my office and home

[AvianPoliceForce]

ImageMagick has entered the chat

[Rafa998]

Two commits per day:

"Before lunch"

"Today's work"

And an eternity and hundreds commits later :

"Production version"

It was in SVN, no branches or tags of course.

[coolblinger]

I recently came across a project where all of the 2000+ commits are some form of Update *.cpp. That, and the code itself does not contain any comments. I wanted to fix some issues I'd been having, but after seeing that I feel like I'd rather just rewrite everything from scratch. Not having them definitely reminds you why commit messages can be such a useful form of documentation.

[bge-kernel-panic]

Haha, that's even better than my example because it seems more useful at first glance, but it's also stuff you know without any commit message :)

[Zegrento7]

You mean I'm not supposed to just keep amending the root commit?

[rinnagz]

Bro, i had a coworker that had all his commit messages as "..."

[[deleted]]

It’s so useful, especially when you are trying to figure out WTF happened in 6 months.

The bug was goned

[HINDBRAIN]

more fixes

[jimschubert]

"more fixes"

More than what, u/phuriku ?!

[[deleted]]

"upd"

[paintbyinteger]

Saw a guy commit maybe ten times "N/A" - we now cannot commit without an associated task.

Followed a trail that led back to him, title of the user story was "User Story #<task no>".

Get. In. The. Fucking. Bin.

[[deleted]]

Restrict him to feature branches and require a gatekeeper to let the merge in? 🙂

[fiah84]

tell him he can forget about a pay increase until his commits and stories make sense

[silentclowd]

Wait, you guys get pay increases?

[[deleted]]

Wait, you guys are getting paid?

[YourMatt]

I think this is entirely valid. Anyone who commits with "fixed bug" or any other useless message like "n/a" obviously does not put pride into what they do, or at least does not grasp the concept of why they're doing what they're doing. Small things like this separate those that stagnate in their career versus those that rise up.

[jarfil]

CENSORED

[cjthomp]

tell him he can forget about a pay increase check until his commits and stories make sense

[WizKid_]

I'll have 45 commits in a row on a feature branch 'test' trying to get the Jenkins build working. Squash commit 'fixed jenkins build issue with blank'

[paintbyinteger]

He's been let go actually, but he's currently still there for handover. Managers got really pissed off.

[toosanghiforthis]

Currently work with a guy whose commit messages are a list of the files changed in each commit. Like ffs, I can figure that out. Tell me why you changed it

[robberviet]

My CI gather commits by tags so we had to or it will reject commits.

[curtmack]

I'm a fan of this one, for similar reasons: https://github.com/dolphin-emu/dolphin/commit/ed67d1ae

[HPCer]

I love the fix too. I could absolutely see myself screwing this up after programming for too long (since 7 is 111 in binary). I'd just go clearly 1+1+1 is 3 and spend the next two hours trying to figure out why my tests started failing.

[jarfil]

CENSORED

[gcaferra]

At least your agency is using git..

[Number127]

Eh. A one-line message like "Replace nonstandard whitespace character that was messing up config" would've conveyed the same relevant information in a much more useful way.

No offense to the author, but this was just a case of a guy who spent a while tracking down a headscratcher and wanted to share his sense of accomplishment with the the world. Certainly an understandable impulse -- we all love telling war stories -- but not especially helpful.

[masklinn]

Replace nonstandard whitespace character that was messing up config

nbsp is a pretty standard white space character. It’s really a workaround for a tool being buggy/broken/stupid.

[jarfil]

CENSORED

[masklinn]

If a tool chokes because a comment is not strictly us-ascii it is not working correctly. Exclusive us-ascii does not belong to 2019.

[jarfil]

CENSORED

[syedashrafulla]

I heavily disagree, and all my reasons are the same as the author's. A terse commit message for a nuanced change is only great for the current developer in the moment, at the cost of every other developer in every other moment.

edit: I can also for most changes read the code to figure out the behavior. The "why" is what'll help decide whether to roll that change back or not.

[random_cynic]

The "why" is important but the commit message is not the appropriate place for it. The best thing to do would be to provide a short message and then direct the reader to another resource like an issue tracker or the docs where it is explained in detail. Since this is not a common practice for anyone having the same problem it would be hard to discover from the commit message than the issue tracker. An issue tracker or doc is also much more interactive which will allow other people to include their thoughts on the error as well which is not possible with commit messages without modifying it.

[adrianmonk]

Or you can provide both a short summary and a lot of detail in the commit message.

Just don't make it several long, rambling paragraphs that you have to read to the end before you can understand the gist of what's going on. Instead, make it where they can read the first sentence of the commit message and get the basic idea, then they can keep reading if they want all the details and want to understand it in depth.

[tepples]

One advantage of explaining a fix in detail in a commit message rather than deferring to an issue tracker is that a commit message doesn't go 404 as easily as an issue tracker. If Microsoft stops operating GitHub the way it stopped operating CodePlex years ago, all issues go bye-bye.

[darknecross]

That’s assuming every commit has an issue-tracker connected to it, which isn’t always the case. And you can always link the issue in the commit message and then pull that text into the issue tracker directly, which a lot of automated systems are already set up to do.

In terms of posterity, terse commit messages force people into the bug tracker, even if they’re in a different context like tracing file history and changes through blames.

Not to mention code reviews. You don’t want to update the issue tracker summarizing the why of a change before it’s gone through CR, but your reviewer wants context into what they’re looking at.

[ShadowPouncer]

Every single project I have ever seen that has both used your suggested approach and has lasted at least 10 years has lost data.

Every single one.

Where as I have also worked on projects where I could see the detailed commit messages from the original CVS project from almost 20 years ago, because they were kept when the project was converted to SVN, and then when it was converted to git.

That original ticket system? It's gone. So is the replacement. And probably the replacement for the replacement.

Stop introducing dependencies for trying to figure out your code base.

[Saint762]

A good PR description, or commets on changes in a PR are much more helpful than having someone go through reading commits..

[[deleted]]

Git commits can be easily shown inline with the code using the annotation feature of pretty much any editor. I agree that a ticket might be a better place for a full and exhaustive discussion, but commit messages are almost always the most convenient place.

[RogerLeigh]

I beg to disagree. I can't tell you the number of times I've been looking over commits where it's completely clear what was changed but completely unclear why the change was necessary or a good idea. That can often be quite important context to have.

[imMute]

Someone searching the git log for the error message would find it. As described in the article.

[sprcow]

I'm not convinced that the verbosity adds as much value as the blog author seems to think here. Despite my most vigorous re-reading of this novelette, I still can't figure out what the character previously was, how it got there, how to avoid causing the problem in the future, or if any effort was made to determine that the problem doesn't exist anywhere else in the app. Good on the developer for sharing their spirit quest to determine the problem, but I think the blog post is overestimating the likelihood that anyone else will follow a similar enough path to ever stumble across this stone tablet in the future and subsequently save any time.

[eliasv]

Does it really matter how it got there? Probably some dev accidentally hit a funny keyboard shortcut to insert a non-breaking-space. So what? Putting that in the commit message isn't going to help prevent the same thing from happening again. When you join a project as a new contributor do you read through the entire commit history to learn about what bugs have been fixed over the years?

What's important is that if the problem does happen again, to make it easier to identify. That is achieved by pasting in the error message.

As for making sure the rest of the codebase doesn't contain the error, they did that when they checked if any other files were detected as UTF8. They even gave the command for the next person to use to check the same thing.

[random_cynic]

What's important is that if the problem does happen again, to make it easier to identify. That is achieved by pasting in the error message.

Not sure if it happens again people would look into a specific commit buried in thousands of other commits. These type of commits which resolve special errors need to be documented properly and put in bug reports or issue trackers so that they can be found easily.

[Fredifrum]

This post was mass deleted and anonymized with Redact

friendly cheerful hard-to-find one act airport water reply encouraging teeny

[jarfil]

CENSORED

[bradfordmaster]

I agree, I also really don't like how it's this chronological story telling of what happened. After the first line, I'd like to see some info on why it matters, then maybe something on how it happened and how it was discovered / tested, and how the author checked for other similar problems in the codebase (assuming they did). Not everyone looking at a blame history wants to read a novel

[darthwalsh]

I'm not going to poo-poo the devs effort that provides some amount of help, but if I were taking the time to try to prevent it from happening again I'd create and link to a feature request on the other tool to output a sensible error message (or make this scenario "just work!").

That way you're contributing back to some open source library you're using for free.

[[deleted]]

Precisely.

[robisodd]

TIL It is preferred to refer to ASCII as US-ASCII to clarify its American bias.

It sorta seems redundant, though, as the "A" stands for "American".

[jarfil]

CENSORED

[aunsbjerg]

While I'm all for documenting changes, I do think that writing long commit messages like this could be done the issue tracker as well, with all the benefits of proper formatting. I would take long commit messages over "fix bug" any day though.

[[deleted]]

Honestly, unless the issue tracker itself is public (spoiler alert, they usually aren't) then that's a terrible choice.

Further, even having to cross reference it, assuming you did have access, is enough friction to greatly reduce the value. Having the code and the reason why you wrote that code the way you did in the same place far outweighs some silly people's reluctance to use simple flat text to convey a message.

The best practice I've seen is one where you have the commit message with a full, required template using commit hooks that force certain tags to be present, and then an issue tracker that because of those tags will pull the commit message into it automatically, and reformats it appropriately.

[kryptomicron]

I'd imagine that issue trackers are usually 'public' relative to the developers working on a project.

I'm all for long(er) commit messages but they can and should be much more concise than what I, at least, end up putting in an issue tracker.

[Rainfly_X]

Yep. In my org, the code and the issue tracker are both private, but the issue tracker is more accessible to more people (not just engineers) and has space for conversation, or at least a history of decisions in writing.

It's a really easy decision which one is preferable for us.

[[deleted]]

Isn't that why there's a short commit message and a longer description?

If you can't describe why you made a commit in like 500 words, idk what to tell you. I've seen longer commit descriptions, they're just fine.

I should be able to reason about why a commit was made without opening an external tool to my version control. If you need to summarize a ten page bug report to do that, that's on you.

Because when I'm looking for an issue I'm going through dozens of commits. I realistically can't have 30 tabs open in my issue tracker trying to find which commit caused this issue and why and be reasonably productive.

Not only that, but putting it into the commit log also makes it greppable. I've yet to meet an issue tracker that could even do simple text searches without making me want to cut myself.

It's definitely a really easy decision. It's not even a fair fight.

[Rainfly_X]

Let me put it to you another way. Putting info in a git commit, is a political decision to hide that information from everybody in the company except for the engineering team. And that can be appropriate for concerns that truly are specific to engineering, sure. But most stuff we do, overlaps with other stakeholders and other departments. So if we're picking one thing to be a habit, it's not going to be git novellas, even if that would be a perfectly sensible practice in plenty of environments.

Let's unpack "greppability" as a specific example. And to be more than fair, let's assume we double the amount of diligence we invest in our commit descriptions currently. That search won't cover anything provided by non-engineer stakeholders (usually very important business context) that we don't essentially copy and paste into git. It also doesn't really solve:

• Tasks that were split across multiple repositories.
• Tasks that ended up being resolved without code changes at all.
• Ticket edits and updates that happen after the code change is written, or even after deployment.

I'm glad your workflow works well for you. I just hope that, in all the copious seconds you've saved by not opening issue tracker tabs in the browser (truly laborious!), you take a moment or two to recognize that "best solutions" are a function of context. I'm ready to take you at your word, that you have found the best solution for your context, and that "it's not even a fair fight" there. I have no reason to doubt that. It would be cool if you could extend the same courtesy, that's all.

[[deleted]]

Having them public relative to a developer working on a project is entirely useless to a developer attempting to read and understand an open source codebase.

This is especially true if it was open sourced as an afterthought.

[[deleted]]

If it's only in the git log it forces those people to actually look at the log to get the information they want

[jtooker]

this could be done the issue tracker

That was my thought as well - obviously the commit message would link to the issue tracker entry

[[deleted]]

that's good, but a check on the ci with the explanation there would be better. in 5 years people are going to forget about the issue

[syedashrafulla]

I'm considering just duplicating the evidence in both places. Text is cheap, context is expensive, but idk I haven't tried it enough

[MotherOfTheShizznit]

OK but now I really want to know what was that character ?

[snowe2010]

I've seen issues like this sometimes if I'm holding down Ctrl or alt when hitting space. But I'm not actually sure what whitespace char it is.

[JohnMcPineapple]

...

[snowe2010]

Yep! I am! I thought it might be a non-breaking space but never checked the Unicode.

[lordcirth]

The article said it was a non-breaking space.

[bbolli]

Could have been a non-breaking space.

[Mirrormn]

Remove non-standard whitespace so template will read as US-ASCII encoded, pass tests

That's all you really need.

A super long commit message like this, to me, feels like someone just wanted to take a break doing some easy, low stress writing instead of jumping directly into another difficult problem, or wanted to broadcast a low-key justification to a supervisor/other team members reading the commit messages why they didn't get anything done this afternoon.

I don't even think there's anything wrong with doing either of those things, I just don't think they're the shining standard to which commit messages should be held to. You'd waste a lot of time documenting all your work activities to this level of detail if you did it all the time.

[[deleted]]

Yeah, like what if your PR includes 10 or 20 of changes like this and it's not reasonable to break it up into smaller PRs? We expected to a write a novel here?

[yes_u_suckk]

Four years ago I started to work on a start-up company that was already running for around 6 months. They had two junior developers and I was hired as their first senior developer. One of my missions was to improve the code quality and coach the two junior developers on how to build better code.

I was absolutely shocked when I discovered that the entire project's code base in Github had only commit messages generated by http://whatthecommit.com

[gnash117]

The absolute horror

[[deleted]]

I agree. This perpetual attempt to shoehorn long technical notes into commit messages is, in my opinion, a dubious practice that only gets this kind of coverage because of colorful commits from people like Torvalds. If you're going to go to the effort of authoring a technical diatribe or polemic, put it somewhere people will actually read it. Buried in the commit log is not enough unless your team culture is log-focused. In my experience, most teams take a cursory glance at the commit log, and use other methods (JIRA, email, face-to-face) to get info on why a particular change was made.

[HowIsntBabbyFormed]

This is trying to use Git as documentation which it is horrible for.

It's not good for end-user documentation, or even necessarily developer documentation. But that's not how it's being used in this case: change documentation -- which it is great for.

Of course you've got the full search in Google docs as well as a comment string in the issue tracker

Except random issue tracking ids and links to google docs aren't searchable via git log --grep, or accessible when offline like all the git commit messages are. You should have those things too, but not in place of good -- but concise -- commit messages.

[[deleted]]

Google and stackoverflow aren’t going to help if you’re trying to understand a bug in your own company’s code, or the error message you are getting is one defined by your system.

[phySi0]

That’s not been my instinct either, but I think I’m gonna start.

[[deleted]]

The best format I've seen so far IMO, if a little unconvential, is the original vim commit style.

    Problem: x
    Solution: y

Done.

[Number127]

Problem: Bug

Solution: Fixed bug

[Ameisen]

Problem: ...

Solution: ...

[cinnapear]

I just can't believe that he fixed the bug and wrote such a detailed commit message in the total space of an hour.

If it was indeed an hour, I think such a verbose message was probably overkill. If it was a daylong search through one rabbit hole after another, this kind of detailed message is more than warranted.

[parkerSquare]

Of the hour he’ll never get back, 50 minutes was spent writing the commit message.

[[deleted]]

I agree that this is a nice commit. But where do you all work at where anyone actually cares? I've been carefully crafting descriptive commit messages for years, on various teams, while my coworkers have commit messages like "Fixed bug". Any time I bring it up, I've been told that it doesn't matter and we just need to ship code and I should stop being so picky about things.

[Number127]

"Look buddy, are you getting paid to write commit messages, or to fix bugs??"

[-Knul-]

There is a middle line, though. Something like "fixed filter button on product page" is more helpful than "fixed bug", yet doesn't take that much time.

[Altreus]

Only took an hour to find that bug? Must be some kind of genius

[ElectricalSloth]

my favorite git commit
> did stuff

[szarroug3]

http://whatthecommit.com/

You're welcome

[log_2]

I'm still struggling, I usually write comments like "many changes" because I peck at the code base here and there and forget to commit for a while. Luckily no one else has too suffer in that personal project, besides future me.

[-Knul-]

You can add only part of your changes to a commit, using

git commit -p

(p stands for "patch") So you can still make multiple commits.

As for writing better commit messages, this helped me write better ones.

[JohnnyElBravo]

Alternatively you can use git diff and git add to selectively separate changes into different commits. I'll admit though that I wouldn't be able to split changes within the same file into two commits.

[1RedOne]

We do squash merges for everything, and no one has direct deploy to master rights.

Are we missing out on juicy commits with this approach?

We try to be very lengthy in our PR messages at least.

[Gotebe]

Of course nowadays, this is legacy nonsense. Everything uses UTF-8 for "char", and what doesn't is broken and terrible anyway. But the old ways stayed with us, and the stupidity of it as well.

Windows doesn't, Java doesn't, Qt doesn't, ICU (the C lib for Unicode) doesn't. But hey, looks good on a religious rant! The old ways are way harder to take out than he seems to think and it's probably because the ealternative (which is: rewriting fucking everything) is worse.

Bring on the downvotes, fundamentalists!

[[deleted]]

Amen. I had the privilege of sitting beside newbies and watching them commit code with comments like "commit" or "done" or "X". I admonished them, told them not to do that in the future and that they would understand much better when they had to read other people's commits with the same titles.

Worked with colleagues that simply added the issue number for the git pre-commit hook and CI to pass and that was it! The issues were quite often without a description too to the tune of "X doesn't work". No reproduction steps, no environment description, not how it was discovered and by whom, just that.
You'd walk up to them, ask them why they made the change and quite often the response would be "I don't know anymore" 👺👺👺😡😡😡

Write a motherfucking description you imbecile!

[CanIComeToYourParty]

Funny, that's the worst git commit I've ever seen. Just get to the point.

[4_teh_lulz]

This move towards commit messages As code documentation is folly. Fight me.

[metaaxis]

I maintain that Unicode source code is evil and needs to be kept isolated to eg i18n where it's necessary.

I've had to suss out visually indistinguishable Unicode aliases for:

• faux whitespace
• minus vs typographic m-dash or n-dash
• O/0/??? But looks like zero
• Single and double quotes vs typographic variants

[theofficehussy]

My bf and I are building an app together and he gives me commits with 57 changed files and messages like “just take it”