Earlier quoted context omitted.
Good point - but what is the use case where another source control system (like SVN?) works better ?
Virtually all use cases in my experience.
You'll have to give some specific examples...
My Favourite Git Commit
121–130 of 389 posts
Re: My Favourite Git Commit
#122OR 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.
You can write the brief summary in the first 80 characters, like OP did. Then write details in the body below, in case someone needs the context. Most tools display only the first 80 characters unless you expand the body.
This case is probably longer than necessary, but I've saved a day of debugging on multiple occasions due to someone (also myself) leaving some lines of context, reasons and reasoning after the high-level description.
Re: My Favourite Git Commit
#123Earlier quoted context omitted.
Good point - but what is the use case where another source control system (like SVN?) works better ?
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 th…
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...)
Re: My Favourite Git Commit
#124OR 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.
Then use `git log --oneline` and you don't have to see the lengthy details, until the inevitable day when you find you need them.
Re: My Favourite Git Commit
#125I 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]
Re: My Favourite Git Commit
#126This 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 cu…
> 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.
Re: My Favourite Git Commit
#127Earlier 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.
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.
Re: My Favourite Git Commit
#128I 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.
Re: My Favourite Git Commit
#129While 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
Re: My Favourite Git Commit
#130I 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.