24 ms·

My Favourite Git Commit

• Chris2048 7y ago
  Should this go into a commit message, instead of an issue/ticket?
  • tomstuart 7y ago
    Yes, because it lives with the code.
  • adamlett 7y ago
    I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road? FWIW, I also prefer READMEs to Wikis.
    • Crinus 7y ago
      > Issue trackers come and go Unless you use Fossil :-P. Or for git/hg/svn/cvs/Folder - Copy(43), one of those ticket trackers that work with files inside the repository itself.
    • crdoconnor 7y ago
      As close to the code as possible means a code comment, not a commit message.
    • Chris2048 7y ago
      > Issue trackers come and go What do you mean? Just put an issue ID in the code and/or commit.
      • adamlett 7y ago
        Let’s hope the SaaS issue tracker you’re currently using never goes out of business or changes the product in a way that makes it worse for you. Or, if you host your own, that it keeps you satisfied in perpetuity. Referring to the issue ID in the commit message is a fine practice in addition to writing good, comprehensive commit messages. Commit messages that consists only of an issue ID are – in my experience – utterly frustrating to deal with. They tell you nothing more than this change is somehow related to this or that bug or feature, but not how or why.
        • Chris2048 7y ago
          > Let’s hope the SaaS issue tracker So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker? > writing good, comprehensive commit messages. Commit messages that consists only of an issue ID Who said anything about only including a tracker id? The issue here is the extra verbosity in the commit message. What will the tracker tickets contain that isn't in your "comprehensive" commit message?
          • adamlett 7y ago
            * So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?* … Or, and hear me out, how about not worrying about that, and just use your VCS to accomplish something it’s imminently well suited for? Also, how do you propose I solve the issue of the issue tracking service maybe going out of business or that of a more compelling product coming along? To me, the primary purpose of an issue tracker is to collaborate on and track work in progress, and that’s what I use them for. I don’t find that they are particularly valuable as historical records of the source code.
      • snorremd 7y ago
        But then you switch out your issue tracker service from something like Jira to something else, and suddenly that ID or URL means squat. A git repository can easily be pushed to any git based service be it GitHub, GitLab, Gitea, or something else, and the commit log and commit hashes stays the same. Porting Jira issues to a different system would probably not preserve those IDs that you entered into your commit message. By all means, refer to your issue tracker in commit messages, but be aware that those references may not be valid in a few years.
        • Chris2048 7y ago
          Just put the old ID in the new ticket, then search. Or put commit hashes into the ticket and search by that. > A git repository .. and the commit log and commit hashes stays the same If issue trackers are so transient and flaky, and VCSs are so solid, then back up your old issue tracker and put it in git. What if your issue tracker stays, but you VCS changes?
  • Sharparam 7y ago
    Since this is describing the commit and what was done and why, the commit seems like a better place. In tools like GitHub, if you make a PR with this commit, it will also automatically put the text in the PR description. I would much prefer this at work over what I usually see with inconsistent commit message styles and not explaining properly what was done, and not following the recommended max length per line.
    • Chris2048 7y ago
      but "why" includes lots of detail about the steps they went through. Why can't "there was utf-8/non-ascii whitespace in the file" Cover all of that? Why detail all the steps to reproduce?
  • shakna 7y ago
    The commit message still logs in the usual way, but it carries the whole set of information with it, in a way that a centralised ticket system doesn't. When a developer is looking at logs for solving some problem, they can easily review the rationale for changes. I'd much prefer the log explaining everything, rather than having to look to a ticket that may no longer exist.
    • Chris2048 7y ago
      > in a way that a centralised ticket system doesn't Why doesn't it? Are closed issues not searchable? It seems to me you doubt the ticket retention, but instead of fixing that, use commits to store issues instead. How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits?
      • shakna 7y ago
        > Why doesn't it? Are closed issues not searchable? Everywhere I have ever worked has changed ticket systems at one point, and even when they are transferred, the transfer is "lossy". Heck, just moving from one JIRA version to another can be "lossy". > How do you provide comments or updates on an issue "relevant to the commit" without arbitrary commits? In the ticket system. I was not advocating that a ticket system is pointless, because they are very useful. But a decent commit message about why a change is necessary, especially when it may not be straight forward, can save you plenty of development time further down the line.
        • Chris2048 7y ago
          I have mixed feelings about JIRA, but if you move to a centralised ticket system you have to plan migration. If you really need to, put more detailed notes into an "Issues" file for commits/minor releases, and clear it on every major release. IMO the given example is more verbose that needed. It should give enough information about what and why a fix is done, but no more.
  • torgard 7y ago
    If you put it in a pull request, that'll just put it in the merge commit instead. I'd prefer it being on the commit itself.
  • Dzugaru 7y ago
    A great question! I’m still wondering why we all mostly use separate tools for tickets and version control (and knowledge base, and collaboration, and management/hiring, the list goes on), given we already know a lot about software development.
    • jimws 7y ago
      Fossil - https://www.fossil-scm.org/ https://www.fossil-scm.org/ Code, commit logs, tickets, and project management are all part of the same repo with Fossil.
    • Chris2048 7y ago
      I think it's more than that. Sometimes I feel there is a disconnect between code history and repo contents e.g the current repo often contains a folder with the entire history of migrations, changelog etc
  • jimws 7y ago
    Absolutely yes. As a developer I can: git log | grep <error message> git show <commit id> I don't have to go looking for an issue tracker and figuring out how to search it effectively.
    • Chris2048 7y ago
      As a developer, you can also search the issue tracker, and don't have to go looking for commit in the VCS and figuring out how to search it effectively.
  • the_duke 7y ago
    This is a big discussion. In a professional setting, companies usually want this information to live in the issue tracker. Mainly to provide insight to managers/other teams without looking at commit messages. But it removes the information from the code: you now need to look at the issue tracker to make sense of changes, eg when looking at the history of a file, or with git-blame. I'd argue that all relevant information that affects the code and architecture of the specific repo should live in commits. They should not only tell you what was changed, but also why; and provide enough context to understand the change in the scope of the repo. All information that is not directly tied to the code, eg cross-repo/product/etc concerns can go in the issue tracker. Of course this only works well with a `git commit --fixup` and squash + rebase / squash + merge workflow. And with monorepos it also becomes a tooling problem.
    • Chris2048 7y ago
      > you now need to look at the issue tracker to make sense of changes Not really, the commit message can be informative without being this verbose. > you now need to look at the issue tracker Doesn't seem like a bad thing to me. Issue trackers are designed to search through.
  • tigershark 7y ago
    In my opinion absolutely no. It should go in a Jira issue and the commit should have the Jira id in the message. In this way when blaming you are just one click away to the full issue description, with properly formatted text and screenshot if needed. It will also be visible to all the team in the Jira board and they don’t have to click on the specific commit to notice that problem.
• ilovepeppapig 7y ago
  RIP git log
• d--b 7y ago
  Yeah but because git is a command line tool, it doesn’t really encourage you to do this in the first place... The title of the commit was enough for me. I wouldn’t have read the content anyways
• hleszek 7y ago
  To avoid those kind of issues, non-ascii characters are forbidden in our code base. They are automatically verified in a pre-commit git hook.
  • unfunco 7y ago
    It should be checked as part of the CI too, if you're doing that, some people might never install the hooks, and some people might git commit --no-verify.
    • hleszek 7y ago
      Indeed but in our case it is for a private repo with only 5 developers. The hooks are installed automatically when running make.
  • rimliu 7y ago
    It's like preventing the headache with a guillotine.
    • deelly 7y ago
      Why? Usually non-ascii characters belongs to translation, and translation usually not belongs to codebase.
      • onei 7y ago
        Maybe it works in your english codebase, but I'd be very hesitant about rolling it out everywhere. For example, Perl 6 supports unicode in identifiers so it's perfectly valid to write your code in Japanese. Another increasingly common example I've seen in python is the use of emoji in command line tools.
        • dragonwriter 7y ago
          > For example, Perl 6 supports unicode in identifiers so it's perfectly valid to write your code in Japanese. Raku/Perl6 also has non-ASCII Unicode operators (they all have multicharacter ASCII aliases, but the Unicode characters are usually more readable.)
• codegladiator 7y ago
  Should have been in a doc or wiki instead of commit message. I have never seen any dev searching for error messages in commit messages. For the rest of the points (makes smarter, builds trust and compassion), if it's so worthy put it on the blog (like this blog post itself) so it can has a potential to reach some reach some audiance.
  • chris_wot 7y ago
    Why not put it in both?
    • codegladiator 7y ago
      Commit messages should be short and to the point. I don't want to read a story to understand what this commit did.
      • l8again 7y ago
        1) Just read the title 2) Maybe have TL;DR section for a summary, and details for who cares. Having a rich commit message is extremely important for capturing code review discussions and design decisions and glue things together for the set of changes in a single place. The advantages far outweigh any negatives from a short commit message that will not give you the "why" of the solution.
      • UK-Al05 7y ago
        Who says this? I follow the linux kernel guidelines, which have large descriptions in commits. After all these guys wrote git. Here's linus's take https://gist.github.com/matthewhudson/1475276 https://gist.github.com/matthewhudson/1475276
      • pdpi 7y ago
        “Convert utf-8 to us-ascii to fix error”. Says right there in the commit title, short and to the point. Absent some automated summarising functionality that produces just the right level of detail for you personally, a concise title and a very detailed commit message that you can skim through to find relevant bits is an eminently reasonable compromise.
• tomashubelbauer 7y ago
  I do feel like Git commit descriptions are severely under-utilised for sure, but I believe there is a reason for that which until fixed, will prevent rich and contentful commit descriptions for flourishing. In the article order: the screenshot is from a commit detail page. How often do you land on this page? You need to specifically click through. If you are in a commit list, the only thing that sets title-only commits and commits with description apart is an ellipsis link which practically blends in with the background. It is not very well integrated nor discoverable. Also I don't believe the commit descriptions render as MarkDown (unlike issues) which is also a shame as it feels like less a doc then. But I might be wrong on this. But even outside of GitHub, how many other UI/IDE plugins and other kinds of Git tools restrict commit display to just the title and put the description on the sideline? Most of them. I think this further leads to the currently low value of the commit message being searchable. Since it is exceedingly rare for good commit messages to exist, no one thinks to search them. People default to Google, when their own project's codebase/knowledge base could hold the answer to their query. I don't have much of an opinion on the commit message telling a story / having a human touch. I mean, it doesn't hurt I guess, but until _full_ commit messages become more "mainstream" (for a lack of a better word), they can be as human as they can, but they will live in solitude.
  • Darkstryder 7y ago
    In the same vein, I wish there would be a standard workflow for putting code inside commit logs. The typical use case would be database migration scripts : IMO they are always a pain to version properly because fundamentally Git and all the other software versioning tools let you describe the "nodes" (in the graph theory sense of the word) of a codebase ("at commit A the code was in this state, at commit B it was in the other state"), but severely lack when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code") I think the temporal dimension of software engineering is still poorly understood, and severely undertooled.
    • codegladiator 7y ago
      > when it comes to describe the edges between nodes ("in order to go from state A to state B, you need to execute this code") Isn't that what a patch file gives ?
• danmur 7y ago
  I wish Git wasn't like some generic term for source control. A little diversity is good!
  • BlueTemplar 7y ago
    Good point - but what is the use case where another source control system (like SVN?) works better ?
    • NoGravitas 7y ago
      There's not really any case where another source control system works better, but lots of cases where they work just as well. Mercurial, for example, is functionally identical to git, but some people prefer its interface. For a highly centralized organization where people only ever work on the organization's intranet, a centralized source-control system like SVN works well enough, and may have some advantages for the organization.
      • BlueTemplar 7y ago
        Actually, I found one just by reading this thread : Fossil has integrated Bug Tracking, Wiki, Forum, and Technotes. Which is great since I would prefer not having to worry about backing up these in the first place ! (Then git also has git-bug for at least some of this functionality...)
    • TwoHeadedBeast 7y ago
      Virtually all use cases in my experience.
      • BlueTemplar 7y ago
        You'll have to give some specific examples...
        • TwoHeadedBeast 7y ago
• iovrthoughtthis 7y ago
  This is my favourite way to write commit messages. Like a blog post on the thing I’m doing. I wish it were easier to gather, annotate and contextualise (perhaps with images) the contents of a commit message.
• vortico 7y ago
  I was working with a research team at UCLA and we used Wolfram Mathematica to process our results. In Mathematica, pretty much any object can be a variable name. You can drag a JPEG of Kim Jong-un into Mathematica and integrate an expression with respect to Kim Jong-un. We'd sometimes get a kick out of that. Near the end of the program, our whole team needed to process the last 3 months of results, but we were all getting consistently incorrect factors off when running our Mathematica notebooks. Five hours later someone discovered that one of the variables contained a stray Unicode whitespace or null character (or maybe a non-Unicode blank Mathematica object, such as a Graphics object with 0 area) that someone must have accidentally spawned somehow before saving and distributed the notebook to the rest of the team. Since Mathematica didn't recognize it as spacing but as part of the variable name, making it a different variable, the result of our integrals were incorrect. E.g. the integral of x^2 is x^3/3, but the integral of xx' is x^2x'/2, so the multiplier would be off by a factor of 3/2. After discovering and selecting it, we "cut" it into the clipboard, pasted it into another Mathematica notebook, saved it, and it was never opened again.
• strictfp 7y ago
  OR you could just write Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII'. I don't want your entire life story in my commit log.
  • vanderZwan 7y ago
    “I didn't have time to write a short commit message, so I wrote a long one instead.”
    • V-2 7y ago
      Pascal! My favorite language
  • konsnos 7y ago
    This is true when you can reference the commit to an issue. Then, seeing the simple commit message you can select if you want to dig up what happened by reading up the comments at the issue. On the other hand it really gets into my nerves when people don't use the task/issue/whatever manager system appropriately. Recently, I lost a couple of days trying to figure out how to compile a c++ framework because the other guy didn't document his pipeline. In general I'm really disappointed by the majority of my colleagues for the lack of comments inside and outside of our codebase and this is a persistent issue, at all the companies I worked for. Me along with other similarly irritated people, always ask for documentation if it is not given.
    • dmortin 7y ago
      > Recently, I lost a couple of days trying to figure out how to compile a c++ framework because the other guy didn't document his pipeline Some people do it for job safety. The logic is if you don't document things and the knowledge is only in your head then you are more valuable, they can't get rid of you easily. If you document everything meticulously, then you are easier to replace.
      • throw0101a 7y ago
• ajdlinux 7y ago
  This is one thing the Linux kernel does comparatively well compared to most open source projects.
• drej 7y ago
  This reminds of a Markdown issue I've had many many many times - sometimes (and only in some engines), headings would not render and I'd only get '# foobar' instead of '<hx>...' It took too long for me to track the issue. When I write '#' using alt-3, I then write a space and oftentimes I don't lift alt soon enough and alt-space creates a non-breaking space (on macOS). And some/most Markdown engines don't recognise '#nbsp;text' as a heading. I suspect something like this happened in the commit linked here.
  • misnome 7y ago
    This happened to me all the time, especially with python2 code without encoding declared (which caused a failure to parse the file because of the comment). I’ve since switched my editors to highlight such characters.
    • jsjw7sbw 7y ago
      Happened to me on linux all the time when writing the pipe operator in a terminal. Thankfully the error message lead me to a fix.
• drej 7y ago
  I love these commits. Then don't have to be this verbose, but they have to tell a story of why things were done. I can sort of deduce the what from the code itself, but the why is sometimes shrouded in mystery. I started with these explanatory git commits a few months ago and they are super useful, even if you're just reading your own commits from some time ago.
  • tigershark 7y ago
    To me they are red flags because it means that very likely who writes this kind of commit messages doesn’t use a proper issue tracking system.
    • UK-Al05 7y ago
      It's better to have these in with the source control system, When you change or switch to a different ticketing system, you will bring these with you.
      • tigershark 7y ago
        If you are switching ticketing systems without migrating all the issues you are doing it wrong.
    • dijksterhuis 7y ago
      To me its beautiful, because it does what an issue tracking system does not do: it explains everything. Who, why, how, what, when. It is beautiful and simple documentation. Issue tracking typically revolves about the who, what, when - not why it happened, or how it was resolved. This is why I believe that code can never be fully self-documenting. I can't understand why the code exists from reading it. All the floofy contextual stuff is missing, and commits like this help to explain the floofiness.
      • tigershark 7y ago
        I think that you are not using properly the issue tracker. You absolutely need as a bare minimum the why and the reporter of the issue. When you do a blame you can easily see the issue id and open it with 1 click to understand why that code exists and who requested the change.
• Ensorceled 7y ago
  I often review commit logs of my teams, especially while we are tracking down problems or I'm making sure the release notes capture everything. There has to be a balance between this and "WIP"; I'm imagining trying to page through the commit log to see what changed when every 1 line change has a 35 line commit associated with it.
  • pricechild 7y ago
    Would `git log --oneline` not help?
  • 1f60c 7y ago
    That’s the beauty of it, the first 50 characters of the first line (IIRC) will be shown as a summary, and this one summarizes 35 lines in seven words.
  • UK-Al05 7y ago
    I believe there's a standard format for this. The first line is the title, then there's a description. These heavy descriptions of commits, are used quite heavily in linux kernel dev
• messe 7y ago
  For anybody wondering, the likely origin of the invalid character is somebody using an Apple Ireland/UK keyboard layout where # is Option-3 (AltGr-3), and non-breaking space is Option-Space (AltGr-Space).
  • laurent123456 7y ago
    I don't know how many times these non-breaking spaces caused problems. I think linters should prevent commits that contain non-breaking spaces. And if really one is needed, it should be encoded as `&nbsp;` or with whatever encoding is relevant.
    • robin_reala 7y ago
      …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.
      • laurent123456 7y ago
        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.
        • supergarfield 7y ago
          Non-breaking spaces are required to typeset French correctly, at least: https://en.wikipedia.org/wiki/Question_mark#Stylistic_variants https://en.wikipedia.org/wiki/Question_mark#Stylistic_varian.... The accidental insertion of non-breaking spaces is a possible issue, and it's a bit harder to detect than other typos, but it's also probably not as bad as other typos. Overall I think it's a bit hard to make the case that they should be disallowed.
• jodrellblank 7y ago
  20 years after UTF8's creation[1], still having to spend an hour of your life "fixing" your content for tools which only handle US-ASCII. [1] https://en.wikipedia.org/wiki/UTF-8#History https://en.wikipedia.org/wiki/UTF-8#History
• l8again 7y ago
  I love descriptive git commit messages. For those complaining about the length: 1) Just read the title 2) Maybe have TL;DR section for a summary, and details for who cares. 3) Use pretty printing for git log Having a rich commit message is extremely important for capturing code review discussions and design decisions and glue things together for the set of changes in a single place. The advantages far outweigh any negatives from a short commit message that will not give you the "why" of the solution.
• withinboredom 7y ago
  One of my favorite pranks is to put control characters in the commit message (like the bell) and then you get an auditory notification anytime anyone nearby opens your commit messages.
  • govg 7y ago
    Does this actually work on modern editors / browsers?
    • messe 7y ago
      Only in the terminal. That said, the first thing I put in my .xsession is `xset -b` to disable the audible bell.
• iicc 7y ago
  This would be terrible without a good subject (the first line).
• simonh 7y ago
  My favourite Github commit was someone removing their password from a test list in a penetration testing tool, because they didn't want anyone to know their password. I just tried, but couldn't track it down. The subsequent comment trail was hilarious.
  • mpettitt 7y ago
    At a guess, https://github.com/danielmiessler/SecLists/pull/155 https://github.com/danielmiessler/SecLists/pull/155 ?
    • olucode 7y ago
      This is the best PR thread on the internet. Thank you for sharing this.
• segfaultbuserr 7y ago
  Also, if you haven't seen it before, read the Linux kernel Changelog. The latest Changelog can be found at [0]. Almost every commit tells a story, unless it's a trivial fix. If there's a bug, it often contains detailed analysis and rationals, and it's a form of important documentation. Although it's not always practical to follow them in personal/work projects - Linux commits are the results of multiple rounds of reviews, and the commit log is its justification - but in personal/work projects, commits are made in real-time as soon as you debugged/refactored something. But I still use Linux kernel as a guideline for my own commit log, at least for new features or bugfixes. [0] https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.7 https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.3.7
• lcnmrn 7y ago
  Someone typed and commited that whitespace character on purpose.
• kissgyorgy 7y ago
  > I don't want your entire life story in my commit log. Then I never want to work with you ever (or any code base you ever touched) because of your laziness and lack of experience working with huge code bases where long commit messages are life-saving. Also you don't care about your colleagues and long-term maintainability. Debugging bugs for months and weeks because of lack of proper commit messages is the most frustrating experience.
  • kyberias 7y ago
    >> I don't want your entire life story in my commit log. >Then I never want to work with you ever (or any code base you ever touched) because of your laziness... What an incredibly aggressive response.
    • Sharparam 7y ago
      The comment it responded to wasn't exactly friendly either.
    • kissgyorgy 7y ago
      Yes, because developers who want to spare minutes of work for others to spare DAYS OR maybe even WEEKS of work deserve shaming. It's very frustrating.
    • twic 7y ago
      Ironically, i'm now curious about kissgyorgy's life story. How did they get so touchy?
    • sam0x17 7y ago
      I think it's an appropriate response to such a blunt dismissal of an entire way of being
  • deleted 7y ago
    [deleted]
  • mepiethree 7y ago
    So you never want to work with... any junior dev ever? I can't think of a single person we have hired out of college who used Git well.
• deaps 7y ago
  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 cuts while documenting, especially for warranty concerns where you deserve to be paid (by the manufacturer) for everything you did that was necessary to fix the concern the first time). I could be mistaken (life-long coder, former network engineer / architect for nearly a decade, but I'm currently in my first-ever role as an actual backend developer). I think I was told to keep commits to one line unless absolutely necessary. I'll have to bring this up though. I like the idea of searching through the git logs for specifics, as opposed to having outlook search through the git commits for actual pieces of code changed, or error codes which might not actually be there. In either event, at least more descriptive, yet still short, messages such as what strictfp suggested "Replace invalid ASCII char. Fixes rake error 'invalid byte sequence in US-ASCII" Although I really like having some reasoning and logic - or how/why in those easily-searchable logs as well. I think some people remember everything and some people don't (although we're all probably roughly similar logically). I have a hard time remembering what I ate for lunch yesterday - that's why I count on good documentation to function as efficiently as possible in the future. I've worked with people who have an absolute uncanny ability to remember 'stuff'. That's impressive, but I do not have that ability myself.
  • chungy 7y ago
    > I think I was told to keep commits to one line unless absolutely necessary. I think I would phrase something more usefully as: keep it as short as possible, but no shorter. I find it to be fairly rare that a commit is so self-evident that only the summary line can do.
  • luhn 7y ago
    > I think I was told to keep commits to one line unless absolutely necessary. The advice I've heard: Your first line should be a concise summary of the commit. This is because a lot of UIs only show the first line up front. (GitHub, git log --pretty=oneline, etc.) However, it's okay (and often encouraged) to go into further detail on subsequent lines.
• nickysielicki 7y ago
  The worst thing about Gitlab and Github is that commit messages are not immediately editable in a PR/MR conversation. You can find conversations like this all over {gitlab,github}-dot-com but you cannot find them in commit messages anymore. Closes #123456 instead of actual background. It's bad for your codebase.
• airnomad 7y ago
  When tax payers foot the bill it's easy to spend entire morning on a single line commit. For many or most guys out there, reality is way different. For one, it's an actual reality, not VC or government funded Utopia.
• beefhash 7y ago
  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/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
  • jplayer01 7y ago
    Final paragraph: > All in all, I believe this proves that software developers as a whole and as a culture produce worse results than drug addicted butt fucked monkeys randomly hacking on typewriters while inhaling the fumes of a radioactive dumpster fire fueled by chinese platsic toys for children and Elton John/Justin Bieber crossover CDs for all eternity. I also nominate this commit.
    • rpmisms 7y ago
      Pure, rage-filled, git commits are possibly the most honest form of art.
      • kitd 7y ago
        It's where the commit message comes in the process that makes them noteworthy. They're the final chance for a developer to vent their spleen or blow their trumpet before signing off on the results of possibly days of work.
      • jugad 7y ago
        George Carlin would probably approve and applaud.
    • thameera 7y ago
      Also from the commit message: > like Shift JIS (sometimes called SHIT JIZZ) Back then when I was working for a Japanese outsourced project, the code won't compile unless the computer's locale was set to Japanese because the C code had comments in Shift JIS.
  • 7y ago
• navinsylvester 7y ago
  I use the following convention to start the subject of commit(posted by someone in a similar HN thread): Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing something; e.g. create a feature flag. Stop = End doing something; e.g. remove a feature flag. Refactor = A code change that MUST be just a refactoring. Reformat = Refactor of formatting, e.g. omit whitespace. Optimize = Refactor of performance, e.g. speed up code. Document = Refactor of documentation, e.g. help files.
  • ShteiLoups 7y ago
    Yes. As is convention, commit messages should be a one line header, then and empty line an a body (if necessary). The whole thing should be width limited to 80 or 100 characters. And the subject line should complete the sentence "If this commit is applied, it will...". It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.
    • deividy 7y ago
      "It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?
      • wool_gather 7y ago
        Can you elaborate on your surprise or objection? It may not be obvious to onlookers what you're reacting to.
        • deividy 7y ago
          well, I think if you start with this kind of bureaucracy, you're doing it wrong. It's not funny. Also, if your app is down, clients calling and you need to fix it fast. If I need to remember this rules to fix this, people will kill me, or I will kill myself :p
• AdrienLemaire 7y ago
  This is a lovely commit, thanks for sharing it. Over the years, I took the habit to request from my coworkers to write semantic commit messages, like https://www.conventionalcommits.org/ https://www.conventionalcommits.org/ You can use git hook libraries like the python pre-commit or javascript husky to check your git commit messages format.
• sytelus 7y ago
  I don't like all these information shoved in to commit logs. This should have been filed as issue and then linked to the commit. The issues are much more searchable, readable, commentable, archivable and interactable in many different ways.
• katzgrau 7y ago
  I'm always intrigued when developers complain that it was "[surprisingly short amount of time] of my life I won't get back." Maybe I'm not as clever, but I'm lucky if I fix an issue like that within a few hours. It can sometimes derail a workday. In fact, fixing in a few hours would be something worth celebrating!
  • Pxtl 7y ago
    Seriously. I'd count my lucky stars if I squished that one in under 4.
• deividy 7y ago
  I figure that so few people read commit messages that in most part of time this is kind of useless. Specially in an early stage of a project. Things will change as faster as I can type a message such as this. Code is simple. Humans overthink. I would prefer a commit message such as: "Fix invalid byte sequence in US-ASCII when running bundle exec rspec." than a dev that keep stucked trying to write a cool message and never fix the issue.
  • avian 7y ago
    > few people read commit messages That very much varies. In a project where 90% of commits are “fix”, “foo”, “commit”, etc. then yes. Nobody will ever read that (or do pretty much anything else useful with a VCS). On the other hand, when every commit message is on the level, the yes, people do read them. Actually, first step when investigating any problem or trying to understand some code is to look at the commit log. See e.g. Linux kernel or some of the Google-related open source projects (chromium, webrtc, etc.) for examples of good, long-form commit messages.
• kenoyer130 7y ago
  While humerous this comment is way to verbose. We prefer the following template > Issue: What is the problem we are attempting to fix Cause: What is the root cause of the issue, since with bug reports this is usually much different then the random musings of the reporter Fix: How does the commit address the cause. Each of these should be 1-3 brief lines
• ilitirit 7y ago
  This really just depends on your team/company/culture. Lengthy commit messages are not really required if you have associated tickets in a bug-tracking or project-management system. More often than not, you'll just be duplicating info.
  • Tactic 7y ago
    This is true until the company changes the bug-tacking and project-management software without properly porting over everything because they use different identifiers. I tend to put a link to the external system with a very brief explanation, allowing someone to quickly assess the what and why with the ability to dig elsewhere for more detail.
    • ilitirit 7y ago
      You could say the same for improperly porting commit messages when switching version control systems.
• irrational 7y ago
  Why are they using us-ascii instead of UTF-8?
• yuriko 7y ago
  A similar story: https://hal.archives-ouvertes.fr/hal-01340384 https://hal.archives-ouvertes.fr/hal-01340384
• stockkid 7y ago
  Contrary to the author's point, I don't think a git commit becomes more beneficial to the readers by adding a human context. Building "compassion and trust" actually distracts readers from the essence of the commit: what happened and why. I am not discarding the importance of human element in collaborative endeavors but maybe such area should be pursued outside of a version control system.
• rbanffy 7y ago
  My personal favorite is one where I actually fixed a bug by flipping one single bit. https://bazaar.launchpad.net/~rbanffy/maas/bug-1443627-increase-node-release-time/revision/3820 https://bazaar.launchpad.net/~rbanffy/maas/bug-1443627-incre...
• Zenst 7y ago
  When reading code, you want somthing simple and to the point most of the time (if that). Yes, it's nice to be able to tunnel down into the details - but this was fixing a bug, the code should just have a short description and more so - the reference number of the bug and if you need to, you can look that up on your bug tracking solution and get that detail. Big problem with detailed comments, things change and comments (like code) can become obsolete/redundant and not reflect the code as the code got updated, but the ocmment did not. No solid solution really and gets down to preference and also mindfulness of the life of code/comments. Would be great to have code that you could rightclick and get the documentation, some woudl even prefer being able to write documentation and that gets turned into code, others would love code that could could be autodocumented. Get's down to taste, preferences and more so, experience. See, every programmer over time will eventually encounter a situation on somebody else's code that they are maintaining, fixing or replacing and find that the comments do not reflect the code. You eventually get down to the stage that you almost actively ignore comments based upon such experiences. So whilst a detailed description in the form of a comment is good, it can and should be elsewhere, either the initial spec and program documentation or in this instance - bug tracking software system and just simple short line with bug reference or indeed just bug reference.
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• ronjouch 7y ago
  Related: Greg Ward - Documenting history, or How to write great commit messages: say what, not why. https://www.youtube.com/watch?v=Jb6ij4eRu6c#t=378 https://www.youtube.com/watch?v=Jb6ij4eRu6c#t=378
• reacweb 7y ago
  Hidden characters again. The answer on stack overflow I am the most proud: https://stackoverflow.com/questions/41061400/perl-join-strings-incorrectly/41062206#41062206 https://stackoverflow.com/questions/41061400/perl-join-strin...
• luord 7y ago
  What I gather from this is that commit messages are a better place for documenting stuff like this than polluting every line of code with often redundant comments. I like it.
  • sethammons 7y ago
    I think the git log is an interesting place to document this kind of thing. Also, there should never be redundant comments. I do think though that lots of folks put things in the git log that _should_ be a code comment. For myself (as most of the people I can think of that I work with), we don't reference git commits unless we are actively investigating a previous change. You should not hide reasons for code being the way it is in the git commit; it should be exposed for direct observation to someone who might edit the code. Ex: '// the following delete call is required to remove the item from the DNS cache to ensure the test validates non cached dns items'. That should be in the code.
• _pmf_ 7y ago
  I'm just told to not write so much bullshit.
• powjfjti83 7y ago
  To an extent I find this lazy and even a humorous take is giving it attention it doesn’t deserve I can complain about anything Can this person build a language that’s still as broadly useful as C that no programmer will find issue with “Oh boy I encountered a particular odd and annoying thing. I won’t bother to offer an alternative. I’ll just complain about others efforts while ignoring they ultimately enabled me to realize my media player project.” Talk about sheltered suburban kids Bet he also tossed his SNES controllers against the wall, blaming Nintendo when he ate shit in FZero Since I have no use for MPV let’s go on a rant about writing more tools when we already have numerous open options to do the same thing Oh right because life is relative and relative to me this is grand standing baby talk So sick of tough guy coders. Oh rly you’re good at seeing the plot holes in text driven computer code? I mean you sit in your basement all night focusing on it so you’re a normal human that gets better at they spend time on Meanwhile, not really contributing in a lasting way to growth of humanity with a media player or your other efforts But of course the efforts that do live long like a general purpose performant language are the kids toys If there’s a joke here it’s this persons life perspective
  • SirensOfTitan 7y ago
    This comment comes across really mean and judgmental. I didn’t read all of the original commit, but it read to me as informative and passionate with all of the frustrations solving a difficult problem comes with. Honestly, this comment is so over the top I can’t even detect whether you’re serious or not.
    • powjfjti83 7y ago
      Opinions are relative. My over the topness is on purpose. The tone of the commit message resonates with exactly the same tone as my post (to me). The commit comment is filled with judgmental, caustic language toward the efforts of others. Yet my opinions about the persons view of “how to design language” are over the top. So you get my point entirely it seems. Are those people less passionate and deserving of such a caustic response by a person who added a media player, a gold cup holder, on top of their foundations, walls, & plumbing? I don’t care how passionate someone appears when the result is elevating their own abilities when their accomplishments aren’t really half as important. Generating an opinion no matter how passionate is not the same as real effort. A true craftsman would build a replacement without the perceived flaws. I’ll give them props when they release their general purpose language that also ends up having a 30+ year history of needing to bend and shift with the times. I somehow doubt his clean room view of what C should be can hang with the shifting hardware landscape over the next 30 years without becoming a bit warty
• doodpants 7y ago
  TL;DR: Written language can be used to communicate information.
• jordigh 7y ago
  I really appreciate this kind of commit message. There’s some very good ones in the Mercurial logs too: https://www.mercurial-scm.org/repo/hg/rev/3764330f76a6 https://www.mercurial-scm.org/repo/hg/rev/3764330f76a6 https://www.mercurial-scm.org/repo/hg/rev/93486cc46125 https://www.mercurial-scm.org/repo/hg/rev/93486cc46125 https://www.mercurial-scm.org/repo/hg/rev/b7a966ce89ed https://www.mercurial-scm.org/repo/hg/rev/b7a966ce89ed https://www.mercurial-scm.org/repo/hg/rev/4a0d0616c47d https://www.mercurial-scm.org/repo/hg/rev/4a0d0616c47d (all modesty aside) Long commit messages aren’t that atypical. Have a stroll through the logs: https://www.mercurial-scm.org/repo/hg/log?style=gitweb https://www.mercurial-scm.org/repo/hg/log?style=gitweb Mercurial inherited this style of commit messages from Linux email-based code review (the Mercurial originator was a kernel hacker), because in that workflow your commit messages are kind of a persuasive essay for why your commit should be accepted. I believe that writing commit messages with that kind of goal in mind, thinking “why should you take this commit?” is a good motivator for writing something good and useful.
• sethammons 7y ago
  I'm glad my near-exact pain has been experienced by others. I had an undefined function call of ' ' in a ruby script years ago. Finally, I turned to a hex editor at the suggestion of a colleague. The culprit was non-ascii whitespace that ruby decided should be a function declaration. Copy pasta error out of a hipchat code snippet.
  • Dumblydorr 7y ago
    Sorry, beginner here, can you explain more simply the difference in the whitespaces? Are they just encoded differently?
    • sethammons 7y ago
      There are full on character encoding introductions. I think an easy to approach one is: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ https://www.joelonsoftware.com/2003/10/08/the-absolute-minim... Basically, ascii is encoded as integers. '32' represents a space. However, ascii is quite limited and if you want non-US-centric characters, you need to use other character sets. For a myriad of reasons, once you go into unicode (the Universal Character Set) there are lots more options for characters. For example, there are multiple whitespace characters. http://jkorpela.fi/chars/spaces.html http://jkorpela.fi/chars/spaces.html These exist to give different widths or other adjustments to text that is non-ascii. What likely happened in the post (and what did happen to me) is copy-pasting from some document that changed a normal ascii space (that Ruby would expect and know how to deal with) into a unicode character that Ruby interprets as any other character. It would be like having a stray 'g' in the line, but you, as a developer, don't see it. Fun :)
      • schoen 7y ago
        This explanation of where the non-breaking space came from feels really likely: https://news.ycombinator.com/item?id=21290159 https://news.ycombinator.com/item?id=21290159
  • 7y ago
• sethammons 7y ago
  One of my favorites, and I can't find it now. Someone's last commit message on the deprecated perl project was in 3D ascii art; something along the lines of "No More Perl." I have a few projects I'd like to write that to :)
• SlowRobotAhead 7y ago
  WHY > WHAT... really helped my documentation, comments, commit messages. I think it’s an under utilized part of coding. I just can’t wait for bigger companies to get onboard. At least in EE/CE it’s tough trying to figure out INTENT sometimes. I see the code, service, headers, docs but you’ve never told me how you intent for me to use this! Maybe your plans were awesome but would change how I was planning to work your thing in. A single page on INTENT would go a long way sometimes.
• nkingsy 7y ago
  Just link to the bug
• derefr 7y ago
  I’m torn about whether I’d like to see this kind of information in a commit message, vs. Something more like: “Remove parser-unsupported character. Closes #340295.” ...where ticket 340295 (wherever, not necessarily Github Issues) goes into more detail about the cause, investigation, and resolution process, as a history of the evolution of said process across a conversation.
  • pojzon 7y ago
    IMHO you should pick a right medium for some kind of messages and I dont think git commit message is the right medium in OP example. Most companies have ticketing tool to keep track of additional information like: how long did it take to solve that issue, was there any input from other people, long "marked up" message explaining what was wrong, how it was fixed and tested (markup is a lot easier to read than console log). Using ticket number already forces you to use "the right tool" to view the message. IMHO I would consider OP example as a bad practice and your example as a better solution.
    • derefr 7y ago
      The other side of this argument—why I’m torn—is that the git commit message isn’t necessarily written by the developer who developed the solution, but might instead be written by a project maintainer who received the solution as a patch, or is copying a fix from a downstream or sibling-fork project, as a standalone patch. In other words: if you have a ticket tracker with this information captured in it, it makes some sense to just link to it. But if you have a mailing list with this information captured in it—in only the loosest amalgamation, where there’s no clear “thread” that contains the whole discussion, and the original developer of the patch might not even be a part of that discussion—then it seems like it’d be important for the final committer to write their own summary of the events that led to this commit, such that people can understand what went on if they weren’t following the list. And where do you put that summary? The commit message. I would argue that maybe this is a core part of git’s design, given that it was developed specifically for the LKML style of “patches first, sent to a list, and then discussed in the context of what they solve”, rather than the GitHub style of “discussion first [on open issues] sparks PRs that attempt to solve [i.e. close] the issue.” Git assumes that you, as an “editor”, are going to be summarizing an otherwise-illegible discussion history for the benefit of the people viewing the commit; and so it provides a multi-line commit message as a place to stow that editorial summary.
• gwbas1c 7y ago
  Honestly, I think better rules are: - Whenever someone asks a question in a pull request, answer it by putting a comment in code. - Include a ticket number (for whatever ticketing system you use) in the commit Why? I find that commit messages are black boxes. They only come out when doing a git blame, but they don't show up in my IDE. Instead, I'm more likely to run across messages like this when they're comments in code or discussions in our ticketing system. I think if we had tighter integration among our IDE, git, and the ticketing system, detailed messages commit messages like this would be extremely useful.
  • adwww 7y ago
    Code comments have a habbit of getting lost during future tidy ups or refactors. If the code is that unclear it needs a comment, refactor it into a named method, where the method name describes exactly what it's doing.
• CharlesColeman 7y ago
  I really like this commit message. I've found that switching to git from more traditional version control systems requires a lot more discipline in some ways. A lot of people just commit, commit, commit lots of incremental changes with no context or story to them. I've seen pull requests with dozens of tiny commits together make up a cohesive effort, but individually are just useless. I've been really having to push my team to spend time to cleaning up their commit history before getting their pull requests merged. I think it's really important to capture the context and indent behind changes. I may be weird, but when I'm fixing an issue, often try to find when it was introduced, which often provides really useful information for the fix. That's much harder to do if the commits aren't cohesive and the messages aren't descriptive.
  • seanbarry 7y ago
    Implement and enforce conventional commits: https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
  • generaljelly 7y ago
    I'm one of those people. I make lots of little commits, it gives me space to really make a mess of coding going down some rabbit hole and performing 'reset --hard' when I get too away from myself, and track what I'm doing locally. As long as each commit isn't causing a problem with CI/CD, and my pull request to master is well documented what is the value added of cleaning up commits? (Junior developer here, looking to be convinced!)
    • adwww 7y ago
      Depends how you handle your PRs. If you squash and rebase within Github or similar, no problem. But ideally interactive rebase before you push your PR and tidy up all those commits into larger topical ones. Eg. "DEV-1 - Write tests for widget X calculator" "DEV-1 - Implement widget X calculator" "DEV-1 - Refactor widget X factory service"
      • deleted 7y ago
        [deleted]
• kgwxd 7y ago
  I had a similar issue with zero-width space recently. Why in the world does that character even exist?
  • lolc 7y ago
    I've used it to hint good line-break positions in a text body where the soft-hyphen does not apply.
• Pxtl 7y ago
  "1 hour of my life I won't get back". I wish. You know when this kind of bug happens to you it blows away half a day at least.
• hnruss 7y ago
  I ran into a similar issue a few years back. There was the same non-space whitespace character spread throughout the codebase. I tracked it down to a single developer, who had no idea why that was happening. My guess was that they were copy/pasting a lot from MS Word documents, but we never found out for sure.
• mcgwiz 7y ago
  Some of this background decision-making information can be included as developer documentation, whatever form that takes, e.g. as comments (usually for low-level) or sibling README file (usually higher-level). Commit logs will have the greatest detail, but they also are the costliest to dig up, often requiring multiple rounds of `blame`. They are therefore most appropriate to include information pertinent at integration-time, namely code review context/justifications. Merge commits (such as those created during typical PR/MR merges) have similar potential to include explanatory background, but at a coarser granularity, e.g. feature level.
• ryantgtg 7y ago
  I feel kinda dumb. I've made many 1,000s of commits since 2011, and I never realized until now that commit messages can have a "body."
• Fnoord 7y ago
  > It makes everyone a little smarter > One thing Dan did here that I really appreciate was to document the commands he ran at each stage. This can be a great lightweight way to spread knowledge around a team. By reading this commit message, someone can learn quite a few useful tips about the Unix toolset: > [..] In the spirit of making everyone smarter: simplicity matters. Using the combination of find -print0 and piping that to xargs -0 is much easier than the mentioned abacadabra of characters. From the xargs(1) manual: > The options are as follows: > -0 Change xargs to expect NUL (``\0'') characters as separators, > instead of spaces and newlines. This is expected to be used in > concert with the -print0 function in find(1).
• carapace 7y ago
  Gah... About a third of my commit messages are just "minor cleanup" or a variation. Should I be ashamed?
  • sixstringtheory 7y ago
    I think shame is an awful motivator. Instead I would praise you for identifying an opportunity to improve :)
• Myrmornis 7y ago
  In an organization I've worked at we used to write good commit messages, about 9 years ago, before we started using Github. Then our good commit messages turned into good PR intros. I think Github and Gitlab etc are fantastic, but I'm a little sad that so much valuable information has been divorced from the git repository itself (and of course, the ultimate fate of those PR intros across the open source world depends on the companies hosting the repo.) Personally, rightly or wrongly, the fact that I can't use Github/Gitlab to contribute to Django and Emacs prevents me from trying to make contributions to those projects. Similarly I find the insistence on using email to send patches, frustrating, when I know PRs (MRs) work so well. However, I guess Emacs and the linux kernel are keeping their good commit messages in their git repo and not losing them to a hosting company. Maybe there should be tooling for automatically converting a PR intro to a commit message.
• pololee 7y ago
  > I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. 1000000% agree! One of my co-workers in my previous job, I miss reading his PR and git message. It's such a joy reading his PR. I still remember reading his PR on introducing Babel to our big, old Rails 4 app before webpacker, Ruby Babel Transpiler came to life. It's like taking a journey with him. You can see his smile, struggle, surprise and all the emotional moments in his commits. He put his findings, why he made this decision, and where he found this solution in the commit msg. I learned a lot just by reading his PR. I think reading a well organized PR, clean git commits and descriptive commit messages (even the code review comments are very useful) is one of the best ways to learn in work, especially for new hires.
• residentfoam 7y ago
  In a professional context (and not only), one would think that this should be the normal expected good practice. But unfortunately, that is not the case. It is so surprising (well not really) to see how, in most cases, developers put so little to close to zero effort in writing proper commit messages and more in general to have a clean commit history. They simply don't care and you keep seeing garbage commits with non-sense to close to empty message and description. Sadly enough this is seen as normal and just accepted. Every single team I have been working with from small to large organizations I always had to pick up on the "write proper commit history" fight. And even after extensive explanations on why you should do that, people simply don't care and they keep pushing stuff like: "fix", "updated class z" and stuff like that. Commit history does not seem to be part of the review process. Sometimes it is just so depressing to see how so unprofessional software engineers are.
  • ImaCake 7y ago
    If it makes you feel better, biologists are often no better. Our equivalent to git commits is labelling tubes and keeping little excel databases of what has gone where. Often databases stop being updated or people give their tubes esoteric labels that are meaningless to those who look at them a year later. As a research assistant in a large lab, I discovered blood tubes with literally no labelling, and often spent hours searching for samples in the labyrinth of freezers in that lab. It is also not uncommon for papers to be retracted because the original authors lost the raw data!
• hyperpallium 7y ago
  General education in a commit is questionable... OTOH find -exec and escaping the ';' (or '+' for xargs-like one line) was helpful (hard to parse --help, though manpage is clear). Now I don't know what to think.
• keithgabryelski 7y ago
  seems like the commit messages lines are in reverse order. tell me what you did. then tell me why you did. leave the saga for the end text so I don't have to read through your musings to get to the meat.
• vpzom 7y ago
  But why was this a problem in the first place? Pretending non-ASCII characters don't exist isn't the right solution.
• Vinnl 7y ago
  I like spending some extra effort on my Git commits (really, typing a message like this doesn't take that long, compared to the amount of time spent doing the change in the commit). It's just a shame that both GitLab and GitHub do not render Markdown in the body of the commit messages, and present them like actual prose rather than a wall of monospaced text.
• toastking 7y ago
  I really like Google's guidelines for commit messages because they enforce a style like this. It really makes dealing with legacy code much easier when you can look at past commits and see that your predecessors were thinking. https://google.github.io/eng-practices/review/developer/cl-descriptions.html https://google.github.io/eng-practices/review/developer/cl-d...
• lmaophp 7y ago
  Ain't got time for this sort of bullshit
• Henry301 7y ago
  click this link http://bit.ly/2IZU6ML http://bit.ly/2IZU6ML
• hayd 7y ago
  Adding a test to prevent this error in the future would also be nice to see, something to mention in code review... Which the commit message makes much easier (without explanation this diff is confusing).
• takeda 7y ago
  A very descriptive commit that doesn't actually fix the bug, only removes the offending character that was triggering it.
• tempodox 7y ago
  The Holy Order of Git Commit Log Bikeshedding and Overengineering have their field day. And they all have it wrong. Any commit log that doesn't compile to an automated build script isn't worth the bytes it's made of.