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.
My Favourite Git Commit
131–140 of 389 posts
Re: My Favourite Git Commit
#132Why are they using us-ascii instead of UTF-8?
Re: My Favourite Git Commit
#133Earlier quoted context omitted.
It's like preventing the headache with a guillotine.
Why? Usually non-ascii characters belongs to translation, and translation usually not belongs to codebase.
Just off the top of my head, test cases would be a valid reason to have non-ASCII in your codebase.
Re: My Favourite Git Commit
#134I 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…
> 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.
Re: My Favourite Git Commit
#135I 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...
My favorite (in terms of dark humor, if we’re honest) is YOLO, one of the more interesting deep learning object detectors. [1] It is the exact opposite of yours in every way. The code is brilliant however. Even the papers are snarky. [2] [1] https://github.com/pjreddie/darknet/commits/master [2] https://arxiv.org/pdf/1804.02767.pdf
> But maybe a better question is: “What are we going to do with these detectors now that we have them?” A lot of the people doing this research are at Google and Facebook.I guess at least we know the technology is in good hands and definitely won’t be used to harvest your personal information and sell it to.... wait, you’re saying that’s exactly what it will be used for?? Oh.
> Well the other people heavily funding vision research are the military and they’ve never done anything horrible like killing lots of people with new technology oh wait.....
> The author is funded by the Office of Naval Research and Google.
He's being funded for this. This is fantastic.
https://pjreddie.com/darknet/yolo/
https://pjreddie.com/static/Redmon%20Resume.pdf
This is the kind of guy I'd love to hang out with.
Re: My Favourite Git Commit
#136I 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 somethi…
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.
"It should start with a capital letter, then move to lowercase, and necessarily will start with a verb.", are you seriously?
Re: My Favourite Git Commit
#137Earlier quoted context omitted.
Why? Usually non-ascii characters belongs to translation, and translation usually not belongs to codebase.
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.
> 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.)
Re: My Favourite Git Commit
#138I 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...
That reminds me of the glorious https://en.wikipedia.org/wiki/File:JIS_and_Shift-JIS_variant....
Re: My Favourite Git Commit
#139Earlier quoted context omitted.
> Some people do it for job safety. The logic is ... Has anyone actually seen this logic work out well for the person that invokes it? Generally the type of person that uses it is one that you probably don't want on your team.
I have! Company promoted the guy and raised his salary because he had plan to leave the company
I know in instances like that, though, my next step would be to start working on contingency plans, as if someone has proven themselves to be indispensable, then that very fact is a risk that needs to be managed.
Re: My Favourite Git Commit
#140Earlier quoted context omitted.
> I don't want your entire life story in my commit log. I[1] want enough debug information in the commit log to be able to reproduce the issue without having to go on web hunts to understand the problem. Especially when the change appears to be trivial on the surface, because these are the ones that can turn out to be rabbit holes. I don't want to have to interrupt you to get this information because you didn't write…
> I don't want go look at an external issue tracker Related question: are there projects that use git itself as issue tracker?
Pagure [0], Fedora's git forge, hosts code, issues, docs, and pull requests as four separate git repositories under the hood [1]. However, only project administrators can clone most of those repos.