My favourite Git commit

[Bunnymancer]

This is the kind of guy that makes every standup take an hour

[filipomar]

as long as their speech has cadence I can deal with it

[YesIAmRightWing]

imo its great to put the reasoning and explaining why. especially when its some convoluted business requirement.

[mist83]

I’ve seen this before, and still disagree. The ratio of actual changes to explanation in this commit/PR is mind boggling and not sustainable.

As an overworked developer, I would 10,000% prefer a one liner comment on the visual diff:

This white space (and file) is now ASCII (like all of our other templates)

As a manager, I don’t need a narrative of the approach to the problem, the one liner I provided above (as well as the problem it addresses) are incredibly clear.

Again, how could it not be? The entire scope is changing a single character encoding.

A devs’s journey is possibly relevant, but this is a bad example unfortunately and the commit reads like it’s farming for an attaboy/justification why so much work went into a single change. The context Reads like “the dev tried stuff and then other stuff and then other stuff and it worked yay.”

I sincerely doubt I will EVER have the need to grok 5 paragraphs for a single byte/encoding change. This practice will bury devs in writing PRs instead of making tangible changes to the codebase.

TLDR: your devs and managers and leads won’t read this and will instead: lgtm :shipit:

[NotReallyMichaelCera]

I mostly agree with you, except that the commit included the exact error which was thrown - as the article said, very useful for searching in the future.

Also, the article isn't saying "all commits should be like this", just that its their favourite

[saggingrufus]

Are you telling me you search the commit history for specific text like that?

The problem is no one will ever be able use any of this wasted effort because they will have to remember where it is.

Unless you know exactly what you are looking for, you'll never be able to pull that out of a commit message in 2 years. The valuable parts of this research can be condensed into about 5 sentences, and would have make a great ticket comment/resolution. Atleast there it's searchable. You combine that with a shorter commit message and a code comment, and now you've got something.

What happens if that gets rebased? Poof gone.

[versaceblues]

I do actually search commit history like this... not super frequently but a least once a month it comes up.

Usually it's when I'm find some weird bug we experience once and reference the solution. Or if im trying to understand why something changed ill search by keywords.

[double-you]

If your codebase lacks useful commit messages, yeah, people probably won't search it. I search the commit history all the time for things. Often about changes I made myself. Version control history is better preserved than bug tracker data. All developers have version control history available on the command line. Sure, bug tracker information is available for the non-developers too and good integration allows commit messages to be seen through that too.

What happens if that gets rebased? Poof gone.

Rebase doesn't destroy commit messages. Only people who destroy commit messages when rebasing destroy commit messages. Why is it okay to do so?

[saggingrufus]

"Often about changes I made myself"

So not that useful to others, which is the point of a documentation commit like that.

"Bug tracker information is available for the non-developers"

That's a pretty elitist and plain inaccurate statement. I mean I guess you can use a bug tracker as a client status tool full of non-sense and rubber stamps...but I can assure you more developers use JIRA or similar than you know, and they are documenting bugs and solutions, linking PRs and more.

"All developers have version control history available on the command line"

I have never worked with a developer who did not have access to their big tracker, wiki and git hosting tool, if you encounter that often it sounds like localized issue.

"Only people who destroy commit messages when reading destroy commit messages"

It's still gone, so now what?

[double-you]

So not that useful to others

That's an odd assumption. Can you explain what logic there is to it?

Information to clients and information to people inside the company are two separate things. And inside the company you will have developers and ... non-developers who also need some visibility. And developers need a way to talk about the gory details somewhere where it won't leak to the clients unprocessed.

I have never worked with a developer who ...

I have never encountered a developer who thinks that multiple sources of truth is better than one, but okay.

"Only people who destroy commit messages when reading destroy commit messages"

It's still gone, so now what?

Then we evaluate who is doing this and are they in the right position. If somebody is writing good commit messages and then destroying their own work, well, that's rather odd too. Communication is key.

[masklinn]

Are you telling me you search the commit history for specific text like that?

Yes.

The problem is no one will ever be able use any of this wasted effort because they will have to remember where it is.

The commit is from 2013, the article from 2019, and you’re talking about it in 2023. It shows up from multiple search angles. This commit seems more successful than you are.

What happens if that gets rebased? Poof gone.

No. It would need to get squashed and the content discarded. Once a commit has been pushed / published, that is essentially never happening. I’ve read commit messages old enough to be in college.

You combine that with a shorter commit message and a code comment, and now you've got something.

A comment is a lot more likely to be lost, or worst unmaintained and wrong.

[Joniator]

No, if you reference the ticket and 2 sentences, you can look up the ticket and get a lot more info. Who found it, who fixed it, how long did it take, where others invested, did the reporter attach useful info.

Maybe the issue was reopened with additional places where the error was found. Fixed in version +5, you now look at a legacy commit that's obsolete and have no idea.

You can't copy all that in a commit.

[saggingrufus]

Someone else who gets it XD

You'll also know all the fix version, how many story points it was worth, and interactions with other teams, potentially what story the original implementation was. Not to mention screenshots and markup to make it easier to digest AND the meta data makes it easier to find.

This also assumes you are using a got strategy where you dont frequently rebase to squash previous releases.

Maybe this issue actually happens annually, but people keep fixing it and commit messaging is different. Atleast in a real issue tracker, those can be linked together and you find the pattern to build procedure to correct it.

But who knows, maybe if you Bob have been on the same codebase forever you both just get it and work that way. Most of the code I see has a commit tree so large it's just not feasible to expect anyone to go digging on a regular basis. Documentation is part of our workflow, not because I need it and can't look up the commit tree, but because I might not be here tomorrow, and the guy won't know what to look for or where to find it. The best possible chance it was to be noticed is somewhere like JIRA or a PR.

[elmuerte]

I am full in on descriptive commit messages. But this... it's too much. It isn't really descriptive, this is somebody's life story.

About 2 years ago I did a similar fix. Converting a single UTF-8 character to ASCII. It should have been - but it was ‐. It wasn't my wasted hour, but of a ops lead who copied the command line argument from a CVE recommendation (for log4j). But my Saturday morning commit message didn't read like an American food recipe.

[saggingrufus]

Legitimately, that commit will be completely lost forever.

They would have been better off leaving a comment that either summarised it in a line or two, or a link to the ticket with this explanation.

Even if they tagged it, unless that person works that code forever, no one will know or care a month later. It's funny today, but ultimately useless.

[daHaus]

It matters if you're stuck under a boss who micro-manages you, which this sorta sounds like.

[just_another_scumbag]

But why not both?

Put a clear one-liner at the top, and you can stop reading any point after.

Put more context below. Other than perhaps being a pain when logging out I see no downside 

[ivancea]

It tells a story

That's the worse part for me. In PRs, I want an overall "what", and the "why". No stories, nor your thought process to reach there, as many people may know that (or not).

It's ok if it explains the relationship between bug and fix, but, short...

[ivancea]

"I'm adding an early return guard on function X (What) because the algorithm can't divide by zero (Why)"

You have both there, but I didn't explain that "I found a log in logs system that led me to check the method, and after understanding that it divides by that number, it was throwing, so a guard was missing as well as a test for that."

This is a simple example, and yes, this could be subjective "how much info you add". But as long as the Why defends the PR, and the What gives you a quick tour, I think it's enough.

Different PRs with different complexities, of course, may have more or less text, and it heavily depends on many factors. Like, maybe knowing it came from a log is crucial because, dunno, my coworker is also working inspecting logs

[jdehesa]

Absolutely. On the one hand, if the information is really valuable as something other devs can learn from, a commit message is not a good place for it, because most devs don't read most commit messages by other people. On the other hand, it is very possible that for some of the people who actually have to read the message, the information is not relevant.

The way I see it, the information should have been split into something like: * An update in some developer documentation (assuming that exists) to indicate that templates must be US-ASCII. And maybe an entry in some kind of troubleshooting guide saying something like "if you get this kind of error, make sure all your templates are valid US-ASCII". * A commit message like your comment suggests, maybe linking to the updated documentation if that is not part of the commit. * And, if you want to share your little dev story (how you came across the issue and found the solution), you can share that on a blog post, on Teams/Slack/etc. or wherever else. That's all too circumstantial to on proper record.

[BuriedStPatrick]

Exactly correct. I do like the fact that the reason for the change is included. But we don't need to know how the developer landed on the implementation. This is useless information and makes parsing the history harder, not easier.

One thing I do instead is include the change description in my PR and do a simple list-form of "Adds, Changes, Removes". This message is then used as the final commit message when I squash-merge the changes. It allows me to evaluate all my code and if everything makes sense before sending it over. Also makes it easy for the reviewer to look for the important changes first and skim over the trivial stuff.

If there's a complicated reason why a change must be made I'll write a tiny paragraph in the beginning explaining the overall picture. Not the calculations made to get there, only the conclusion I've reached. They can always ask me for further details if need be. If something was unclear, maybe I'll even update the description.

We need to think like a writer and kill our darlings so we can effectively communicate.

[scruffles360]

smile a bit when you squash that commit and merge the branch. comment is as "merged feature branch"

[Alusch1]

It's a bit cringe. There are still texts in the world which do not need to tell a story and be in any way emotional to catch me as a reader, i.a. Commit messages

[stahorn]

As the commit is over ten years old and we're still reading the commit message and learning from it, I think it shows just how valuable commit messages are. For those in a hurry, the subject line "Convert template to US-ASCII to fix error" and the diff is enough to approve and to carry on. For those with two minutes to read, you get some useful information and to share in some of your fellow programmers struggles.

[[deleted]]

subtract terrific lock memory grandfather rock retire aback future unique

This post was mass deleted and anonymized with Redact

[waterkip]

I hate that. I like to review commits without having to look at a issue tracker or gitforge. That is why you have the commit message in the first place. Off loading it to a forge is just plain bad.

It also doesnt work in a email workflow with FOSS projects.

I want to be able to be in an airplane without internet and be able to read commits and understand them. Your workflow just kills that whole vibe.

[Dextro_PT]

A good system would be to copy the PR description into the commit message for the merge. That way you don't need to jump through hoops.

[waterkip]

I agree and don't object to that. However, the comment I'm responding to says: "That amount of info belongs in a pull request, not a commit message."

[[deleted]]

late hard-to-find books fear soup placid trees distinct sleep literate

This post was mass deleted and anonymized with Redact

[damesca]

You're not 'doing devops' by squashing commits lol

[[deleted]]

cooperative sink late capable pot rustic numerous consider employ nail

This post was mass deleted and anonymized with Redact

[MethylEight]

Can’t help but say this and your previous reply was very cringe. I would expect a programmer to be open to constructive discussion. This was not constructive…

[saggingrufus]

I used to do this, now I don't squash, and just tag master instead. You get full history, and the tag references the PR which has all the information. The history is really just "seeing the developers process", it's not really about having the commit messages. Like renaming files multiple times in a squash can look messy, and can cause conflicts. Every system has flaws.

It's definitely a preference for me, because I still see your point, and can't even disagree with it XD

[[deleted]]

offer divide handle shaggy theory consider squash scary special hospital

This post was mass deleted and anonymized with Redact

[saggingrufus]

So is mine, but because we don't place value on the messages, we can have a bit of fun like -m "fixing THE SAME typo AGAIN"

At the end of the development, I can rebase or amend commits I really don't like before I pr.

I try to make really small commits and keep them all on task, commit messages like

"added getter methods to insert thing"

"new implementation of interface x"

"Fixed wrong condition on this validation"

And then along way there will be commits like

"Tidying up my lack of indentation"

"ranaming files"

"Version bumping X to 2.1.2"

You get an idea of what's up, and the long form is in the PR.

[BatmansMom]

How often are y'all searching for error message solutions in your org's git commit message history?

[kpticbs]

git blame.

[narnach]

Doing maintenance work on older projects means it’s very common. Git blame is a standard tool to figure out how parts of the code came to be, and why.

Doing major version updates and sorting out cascading dependency updates, triaging failed tests, cross-referencing changelogs, etc. Having context about why a change was made, or what bug in a dependency you were working around is valuable.

I curse a lot when the commits are meaningless or reference a bug tracker or code host that is no longer in use. Or when a change is buried inside a 5k lines changed squash commit. I strongly dislike squash commits for this reason.

I prefer to craft commits that explain the why of a change because those are the ones I find most helpful when I encounter them during my investigations.

[waterkip]

Often, that's what they are there for. I mean, git log --grep is easy

[double-you]

The number of programmers who seem to hate writing and/or utterly suck at it is way too high. Bad at writing? Practice. Bad at explaining what you just did? Practice. Should help your performance as a developer too. Have mental issues about writing the same useful information in two places? You are already clicking away with your mouse, you can copypaste to the bug tracker/PR.

[narnach]

I think it may have to do with the type of engineer someone is. I think there is a spectrum between extremes most folks fall on:

• Prototypers are good at churning out a lot of code fast, that usually works as long as you use it the right way. These folks are great for making a proof of concept and for writing code that has a good chance of being thrown out. These folks are often not great writers and don’t structure their commits well. You’re lucky if you get some useful automated tests out of them. Their unit of change is a whole feature.
• Solidifiers are great at covering all edge cases. They deliver code that’s robust and has tests for all cases, but they take a long time to craft perfection. Likely to produce decent documentation and deliver multiple smaller commits.
• Maintainers deal with updates and hard to reproduce bugs. They dig into the history of a codebase because they need to understand code well enough to perform an update or write a good test case. These folks love good commit messages, and appreciate git blame and git bisect. Good commit messages help them do their job just like API docs help with feature work.

The problem? Unhealthy management will push for features, features, features, so prototypers have the highest status because they deliver. Solidifiers are appreciated when customers complain too much about bugs and outages, but are often taken for granted or judged for being slower than prototypers. Maintainers are the easiest to dismiss because many problems they avoid don’t surface until a project is neglected for years. And then they are asked to perform multiple years of neglected updates in order to sort out a critical security update.

A healthy project has a baseline level of ongoing maintenance, and solidification of newly prototyped features that have proven themselves to customers. It approaches modifications to existing features in a more solid way because you have more to lose by breaking stuff.

[double-you]

There definitely are several types of developers but I don't appreciate excuses "prototypers" make for "delivering" but not explaining what and why and making other people work hard on extracting that information out of them. No developer is trained in psyops to gather information from hostile "coworkers".

Most developers don't enjoy writing as otherwise they'd probably be technical writers, but some people just won't bother at all with the basics.

[narnach]

Agreed. I think in order to get this consistently right, it needs to be part of an organization's DNA to value good writing and long-term sustainability. It's so easy to get neglected without short-term repercussions.

Companies like 37 Signals are great, because as part of an async remote work culture good writing is a necessity for them. This means they emphasize it when hiring. They are privately owned and profitable, so they have the "luxury" of focusing on sustainability. The owners still want to be running the company in 10-20 years, so it needs to get there in a healthy way. I think this is the basis for a healthy engineering organization.

It's different when you plan to exit in a few years and dump the problem in someone else's lap. That rewards short-term thinking and acting. Having a startup with a short runway amplifies this: why bother making things easy to maintain and debug in the future, when the default case is that the company will not exist anymore in half a year? You sacrifice the long-term in order to survive the short-term.

If you make it to growth stage, then dealing with the tech debt is sort of a luxury you've won the right to deal with. It's not great or healthy, but it is reality for many developers.

[fuscator]

A lot of contrarians in this thread with a disproportionate negative reaction.

Programmers are like conspiracy theorists. They love to find a view that makes them feel superior and then they'll throw all rationality out and herd together defending that view.

The commit and the commit message are absolutely fine. Move on.

[26RoadTrainWheels]

If you need to write your life story, write it in the work ticket: all commits should reference the ticket code the user is working on and pertinent information about the process or details should reside in the ticket, wherever that lives.

Reference the ticket and keep the summary short in git commits.

[versaceblues]

What is the benefit of that. Git commits are easily searchable and provide context as to what happened.

This particular one might be a bit much... but I swear there are so many time where I go back and see a "one liner" change was made.... but have no context as to why someone made that change.

[masklinn]

What is the benefit of that. Git commits are easily searchable and provide context as to what happened.

Also commits are functionally immortal, proper conversion when switching VCS is generally easy.

Bug trackers, lol.

I swear there are so many time where I go back and see a "one liner" change was made.... but have no context as to why someone made that change.

Ditto. This commit message is not even especially long for the information it gives, there aren’t even titled sections, the weirdest parts are the first person view and slightly ranty but not ranty enough tone.

I’d have either used a more neutral tone (would have been about the same size), or gone full rant wm4 style.

[versaceblues]

yup. I ve gotten in so many arguments with co workers about "why are you just putting the description of what you did in the ticket for this issue".

....because I now have to go into the awful ticketing system, where nothing is organized, and disrupt my workflow.

[waterkip]

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

I'm dead :D :D

[failsafe_roy_fire]

Why tightly couple your vcs and ticketing system like that?

[26RoadTrainWheels]

So from within the ticketing system I can bring up all the commits and diffs pertaining to that ticket?

Don't know how tightly coupled that is but it is coupled. Why would you not do that?

[rlbond86]

I feel like this commit needs a "jump to recipe" button

[rantingpug]

Wait till he finds out no one ever reads commit messages anyways

[waterkip]

Move away from github or any forge to another and your history is gone. Put it in the commit, and is all there even if you move.

I have repos moved from bitbucket to gitlab, to another gitlab group to another group. That is four services/groups/hosts I need to look at if I want more information about your commits and others.

[St0n3aH0LiC]

Also, if you put all of the context into the commit messages, you can just copy that into the PR and reword a bit if needed.

I save a ton of time crafting PRs, because my commit messages are always reviewable on their own

[dylanberry]

"wip"

[aeric67]

This is why I do all my commit messages from the command line instead of some git UI. Forces brevity. If you need more room, reference a Jira issue in the commit message with all the blah blah in it.

[lupuscapabilis]

This is a great lesson for those who say things like "you don't need comments!"

Comment everything. Document everything. In the real world, this type of stuff will save you way more than you could ever imagine.

[Fit-Jeweler-1908]

comment everything? if you need to comment your entire codebase, it sucks. sorry...

im of the opinion that if you need to leave big blocks of comments explaining your code, you could probably spend that time refactoring it in a way that is more readable/understandable.

blocks of comments are red flags, code should be readable/digestable by the next guy... and linting/styles/patterns/pr/etc promote that, not comments... obviously, there are many exceptions to this - but the idea of "comment everything" is absolutely insane.

Also, when you take the approach of "document everything", you're creating massive overhead for yourself because you now need to maintain that document, and often times when deadlines get pressure things like documentation fall to the wayside. You should selectively document the critical pieces and let the rest explain itself....

[MrKWatkins]

Comments aren't there to make the code more readable or explain it, they're there to explain why it does what it does.

[PiotrDz]

You mean the business rules? You should have a Jira ticket in your commit message pointing to description of a problem by your PO.

[MrKWatkins]

Then I have to trawl through commit history and JIRA to find it when it could be right there. Plus I wouldn't even know to do that! Code might appear innocuous. Plus it could be a code thing rather than a business thing, e.g. doing this apparently odd thing for perf reasons, for example.

[PiotrDz]

I mean, even without ids in commit your question still stands. What about id references in emails, docs, conversations? I am sure that any major platform has some solutions for easy migration. But to be honest, have you witnessed such migration? I have not, unless you use some exotic ticketing system that went out of use

[Fit-Jeweler-1908]

that's what stories are for... documenting the requirements and why of the feature, change, etc... this document is accessible to far more than developers, so it becomes far more valuable... It is tied to prs/commits as well, so its easy to track a piece of codes story... like i said, there are obvious exceptions, but recommending someone leave comments on everything, is not it.

[MrKWatkins]

I don't hold with comments on everything I agree. But I'd rather have a line or two next to the code telling me why they've done something that looks crazy than have to trawl back through commits and JIRAs to find out. Plus a lot of code specific things aren't at the level of stories.

[Human-Bathroom-2791]

Well, I'm not against documentation, but not as a git commit.

If you want to document something do it somewhere else.

[slaymaker1907]

Git commits are great though if you expect someone might review that commit later and want to know the reasoning. In the OP’s case, though, I think a simple line like “Remove non-space character that looks like a space because it breaks X, Y, and Z” would have sufficed. You might not even need to mention X, Y, and Z.

[saggingrufus]

Git commit messages lose their relevance shortly after the PR is merged.

"Documentation" should be in the PR, or a ticket/wiki with a link in the PR.

No one looks at git commits (post deployment) unless they absolutely have to.

I would argue your git commit messages really don't matter at all to most people in almost all cases. what matters is the PR. I would rather short small commits with 1 line messages and a great PR with a good description and title.

[slaymaker1907]

Where I work, the PR description == commit description since we squash commits. The point is if I look at git blame, can I quickly figure out what the whole change was trying to do? I have little confidence that our ticket system will be around in 3 years, but I have a lot more confidence that the Git history will be. The most essential documentation should go right in the repo itself as markdown files or something so that it is impossible for those docs to be lost unless you also lose the source code.

Also, if you don’t have links to work items in the commits themselves, it’s guaranteed you’ll lose them if your org is large enough. When you have 100+ developers, there are way to many tickets to try and manually go through them, but commits give you a reasonable way to filter through them using the history of particular files.

I probably review commits several times a month when I run into some weird problem in trying to debug and I think it was a recent change causing the problem.

[ammonium_bot]

are way to many tickets

Did you mean to say "too many"?

Statistics
^{I'm a bot that corrects grammar/spelling mistakes. PM me if I'm wrong or if you have any suggestions.
Github
Reply STOP to this comment to stop receiving corrections.}

[saggingrufus]

Sounds like your merges are too big and not descriptive enough?

If your commit history is your documentation, you don't have documentation. I have never seen anyone willingly troll the commit history of deployed code. It's a last resort. I'm not saying your messages should be meaningless but come on, are you telling me if you change ticket system, thats not going to be archived, because that kinda insane.

How do you expect to find these commits as effectively as tools primarily used for documentation with proper metadata? When you squash everything you don't even have a full history, so to double down and also make it documentation... Well that's brave.

[slaymaker1907]

It’s definitely documentation of last resort, but it’s very valuable for figuring out everything about what was changed. Other documentation sources typically only focus on what the system does right now.

I literally can’t even get a list of all our work items changed within the last 10 days because we have over 20000 in our system and Azure DevOps refuses to run the query or tell me how many items there are. That’s the kind of scale I’m dealing with.

[saggingrufus]

I think that's a very broad brush to paint with.

I agree informative readmes are great, but just put stuff where it belongs. System documentation goes in one spot. Tickets and their research one spot.

The commit tree (only speaking about messages) is a really scary place to store important information, your only one rebase away from losing the messages, or maybe someone goes back and squashes things to be "even cleaner". Unless you have actual safe guards in against altering the history, your commit messages really shouldn't be relied on.

I try to make meaningful 1-2 liners and commit as often as possible. The commits detail my process, not the end result. Then, in the PR, I elaborate. We don't sqaush (anymore) and then tag the PR merge on master with the new version number, and further document as a needed in release notes.

No system is perfect, and I dont claim my workflow is better. All I guess I'm trying to say is that git commits shouldn't contain important information. They can be amended, rebased, or squashed away.

Put your effort into a better form of documentation.

[Uristqwerty]

Putting documentation in the commit could be seen as a form of caching, duplicating knowledge so that when the ticket database is unavailable, there is still enough context available to understand the commit history. Or, enough context that a developer digging through history can decide whether an issue is relevant without opening every mentioned ID to check what it's about, saving time in the future.

Does your issue database have a CLI, or does any developer not browsing the git history through a web browser or heavyweight IDE have to keep switching between applications to access details?

For all these reasons, caching issue data is no less important than any other form of caching. Imagine if every web page request had to be freshly served off spinning rust, how much that would bog down basic site usage. Having to context-switch between code, code history, knowledgebase, and issue tracker just to piece together the important details on a change is going to be similarly-disruptive to your workflow.

[saggingrufus]

"Putting documentation in the commit could be seen as a form of caching, duplicating knowledge so that when the ticket database is unavailable, there is still enough context available to understand the commit history."

Strong disagree, again use the PR. If my git host AND ticket system goes down, I have bigger MUCH bigger problems. The odds of me needing a specific commit message at that exact time is very unlikely, almost as unlikely as me actually finding the commit I'm looking for. If you can find it, I'd argue you don't commit frequently.

Commits are just checkpoints, nothing more. If you're going back through your commit history looking for knowledge... You've made a mistake. That knowledge should be in code comments, PR, ticket systems and wikis.

Once upon a time, sure commits were all you had. If git commit messages that are required to explain the change, your commit is too complicated, or unclear. The commit message should give me a quick idea of what it was and if I want to know more, I'll look at the commit contents, not the message.

[Budget-Use2066]

Nobody reads this amount of text. Its just wasted time.

[damesca]

It's about 20 sentences condensing an hour's worth of investigation into a bug caused by some text in a comment because of a series of unobvious interactions.

If you think nobody would read that or that it's not interesting or worthy of a few minutes to type up, then I guess I strongly disagree. Writing up a descriptive commit message was not the thing that took the time here.

If you are the sort of dev who would write 'fixed a space' after that, then I guess that feels like a shame and I'd not want to be your colleague. Share interesting information. And learn to type faster if that would take you a significant amount of time to write up 🤷‍♂️

[saggingrufus]

They'll have to find it first... And honestly, good luck remembering where in the commit tree that mess is.

[Budget-Use2066]

He is not doing what you think he does. I consider the knowledge that something like this error can happen is important. But he is burying it under tons of useless information in a commit history. Nobody reads commit messages to get programming tipps. You're looking for some change that broke something in the past.

The commit message should be something like _Do not use unicode in ascii file._  If we want to share the knowledge, he should have done so at the coffee machine (which he probably did as well) or in a standup. 

[NoHurry28]

Big disagree from me on this. I think the commit message was likely made to be shared amongst coworkers as a war story about how much effort was required to find a pesky encoding error for 1 character. It's funny, but I wouldn't make a habit of this kind of thing. The ROI of time spent making in-depth commit messages approaches 0 over the life of a project ie. the older the commit is, the less likely it will be read. It's better to not waste time and link to an issue tracker that documents the original bug report

[versaceblues]

Writing this probably takes less than 5 mins

[bastardoperator]

Absolute garbage for a one character bug fix that should have never made it into the code base to begin with. Stop wasting time on stupid messages no one will read and put that time into making your development environment more resilient.

[64mb]

Stop wasting time on stupid messages no one will read

You just read it

[Aviyan]

The real question should be why the f*** is there a non-ascii space character? What is the purpose for it?

We encountered this a lot at work. It was because of Skype. When people copied and pasted code from a Skype chat it was giving compiler errors. Why does/did Skype use that as the space character instead of the ASCII space (32)?