231–240 of 389 posts
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.
Obvious point is that commit messages can be used besides what was done as a form of documentation and teaching tool (why, how).
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 commi…
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…
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.
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…
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.
Earlier quoted context omitted.
I was reading it and kind of interested, and thought this line was funny: > I have a lot of hope that most of the people using computer vision are just doing happy, good stuff with it, like [...] tracking their cat as it wanders around their house And then suddenly realized I've wanted to do exactly that for a long time. Well... specifically install a camera that can detect my cat on the counter (and not my hands doi…
On the topic of cats vs automation, I'd recommend reading this post [1] describing the arms race created by the writer's cat attempting to break into an automated feeding machine. HN discussion here [2] [1] http://quinndunki.com/blondihacks/?p=3023 [2] https://news.ycombinator.com/item?id=13230904
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.
Pasta and computers are always a bad mix...
I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
This message says much more about the author than it does about the commit.
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.
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…
The commit was complaining specifically about the way locales were designed, not C as a whole. While C was very successful, I don't think you could argue that C locales ever reached the same level of popularity. That being said I do agree with you that this complaining is not massively productive. Dealing with localization and non-ASCII text is notoriously difficult. Look at Java, Python 3, Windows, PHP 6 and how man…
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.
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…
By all means put the ticket number in the header line, along with type of patch.
But do yourself a favor and put enough context in too. Doesn't have to be all the detail.
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…
It’s a shame you see it only as complaint, the brilliant thing about the text you’re replying to is that it educates the reader as to the bigger problem, as well as being very funny. Does your complaint do either? Understanding why C locales are broken may very well contribute to the lasting growth of humanity. Did you note that Eric Raymond fully agreed?
You’re assuming also ESR is some God incapable of normal human failures in reason.
The issue is a real thing in C.
Github to me is Arxiv. I don’t see a lot of research papers making a point with caustic words for the universe. But my background and education is math, my way of having to communicate issues and ideas is different.
To me MPV is a few build scripts pulling from source. Surely a true craftsman would know how to avoid this issue up front. This feels like complaining a Ford Focus won’t go faster after taping model rockets to it.
They know what it is, how it works, the process for the design, it’s legacy. And despite the issue shit still works and society is not worse off. We still treat each other with the same level of disrespect by letting scores of people die of curable disease.
So yeah to my mind this is whiny crap. An emotional rant by someone with no real responsibility and not really taking any either if they’re going to complain but not get involved in the design process.
Also I don’t really care about social media norms and use throwaways liberally.