
Commit messages guide - walterbell
https://github.com/RomuloOliveira/commit-messages-guide
======
areyouseriousxx
This is one of those interesting bits where things feel more like personality
types as opposed to ways to create maintainable software. I have yet to see a
project fail because commit messages were or were not in imperative form or if
the first letter was capitalized. I have no problem doing it if someone in the
team finds it important, and I have no issue if someone on the team does not
do it.

The same is generally true about rebasing etc.

Due to the high visibility of commit messages, a lot of details certainly look
pretty bike shed-ish.

What can be important is simply a general concept of meaningful messages when
they make sense. For example, bug fixes that may not be obvious by looking at
the code, should probably have a reasonably detailed description of the bug.
Commits implementing a brand new feature and involving a ton of changes,
probably don't need a whole lot more than what the feature is and what is the
expected behavior. Possibly some info about potential future bugs that could
happen. When updating the readme, "Updating documentation" is just fine plenty
of times.

Otherwise, probably just make sure you include some important keywords to make
it easier for people to git-grep and I think most projects will be just fine.

There ar certain personality types that really enjoy organization and rules.
And the feeling of security that comes from having a well defined set of
procedures everyone must follow. It really isn't about making software more
maintainable based on any existing research we have about how maintainable
software is. But if it benefits some of my coworkers mental health by
following those rules, it really doesn't take me any additional effort to
follow those rules so I have no problem doing it.

~~~
remilouf
I don’t completely agree. By taking the time to write commit messages you are
documenting your code at a fine-grained level. Think of it like a short email
that explains to your (future) colleagues and future self what you changed and
especially why you did it.

A good git log prevents unnecessary headaches and saves a lot of time. Typical
situation: you just found a couple of lines whose purpose is not completely
obvious. If the author is still there, you both waste time discussing. If
she/he left the company and you have to figure it out by yourself. Now imagine
using git log to identify when these lines where introduced/changed and
getting an explanation as to why.

So yeah, writing good commit messages can feel like a waste of time. Like
writing good code can feel like a waste of time. You should not be doing it to
please your colleague, but rather to contribute to a maintainable codebase.
It’s worth the extra minutes here and there.

Bonus point: less documentation to write.

~~~
lmilcin
Nobody questions it is important to write clear commit messages. The issue is
being nitpicky about what exact form is being used like whether to capitalize
first letter or not.

When I look at the repository I am happy if I can understand the messages at
all. It's challenging to get people to group changes in a logical way so that
the commit makes sense. I am not going to pick on somebody because he used
wrong tense or did not capitalize first word of the message if the changes are
grouped logically and the commit mentions the correct ticket and purpose of
the commit.

~~~
remilouf
I feel it reduces cognitive load, like proper formatting of code.

Do you enforce consistent code formatting in your codebase (using CI, maybe)?
If so, why wouldn’t you do that with commits?

~~~
int_19h
I used to be in the camp that cared a lot about formatting, but over time
realized that it's more my OCD than any practical reason.

At this point, the only reason why I like consistent code formatting rules is
because they prevent bickering between people who have strong opinions on how
things should be. When there's a rule, even if people don't like it, they
abide by it. When there are no rules, everybody who thinks that there _should_
be rules starts bikeshedding what they ought to be.

But as far as code quality goes, I don't think it matters much.

------
red_dinosaur
The repository does not follow its own guidelines.

Also, there's a lot of unnecessary stuff in there. Capitalization and
imperative? Not at the top of my list.

The relevant points are nicely summarized by Linus Torvalds:
[https://github.com/torvalds/subsurface-for-
dirk/blob/a48494d...](https://github.com/torvalds/subsurface-for-
dirk/blob/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88)

~~~
dcbadacd
I heavily dislike the hard wrap requirement. Why do that if our clients could
do it nicely, based on screen size, preference and everything?

~~~
Reelin
Because very often the client will be some piece of command line tooling that
doesn't do those things.

[https://commit.style](https://commit.style)

> Git is strongly opinionated that the author is responsible for line breaks;
> if you omit them, command line tooling will show it as one extremely long
> unwrapped line.

~~~
int_19h
The terminal will still wrap that long line.

In general, this approach is broken by design, because the author cannot know
where the commit message is going to be displayed. It might actually be in the
context where wrapping at 80 or even at 72 is still not long enough (a tooltip
in an IDE, say). Or it might be one where it results in a lot of wasted
whitespace. It's much better to fix anything that does not handle wrapping
properly to do so, than to impose an arbitrary limit that only really works
for one environment.

------
chipotle_coyote
While I've naturally gravitated toward the "capitalize and use the
imperative," I've never been down with the "good commit messages are 50
characters or less" mantra. Why 50? Is there an important tool that breaks if
my commit message is 55, 60 or even (gasp) 70 characters? Is there a real case
to be made that "Add total vocab entries per capsule limitation" is a good
commit message that becomes an utter irresponsible trash fire if one spells
the entire word "vocabulary?"

Yes, short, clear commit messages are good. I'm not saying "write a
paragraph"; I'm not even saying that it's bad to have an arbitrary maximum
length beyond which a commit message can be considered poor form. It's just
that 50 is a _weirdly_ arbitrary choice.

~~~
regularfry
The commit header becomes the email "Subject:" line. 50 characters is less
than 72, and allows for the inevitable "Re: Fwd: [Re:] Re:..." mess of email
threads, without losing context.

~~~
Joeboy
Is that _the_ reason? So if your commits aren't getting emailed anywhere, you
can ignore this rule (within reason)? I would think only a small minority of
git projects have email notifications enabled.

~~~
jstimpfle
Several ways to display the history, like "git log --oneline", or versions
thereof that include the author and date, do profit from short head lines.

~~~
jlg23
But "For long commit messages, give a summary in up to 50 characters first"
solves that as well. There are good reasons to use longer commit messages:

* Link to issue in tracker (Projects can liver longer than the use of a single tracking software or use multiple in parallel - e.g.: public and private ones).

* Important changes in behaviour might warrant a deep link into the relevant docs, even though they are part of the commit.

* Justification why something was changed can be lengthy, especially in a loaded environment (crunch time, intra- or inter-team politics).

I am aware that various workflows exist, supported by various tools, that at
least partially solve the problems I mentioned. But the larger the number of
people involved or the longer the history of a project, the harder it tends to
be to agree on a complete chain of tools just for the sake of keeping commit
messages short.

~~~
jstimpfle
Of course. Noone here said that the commit header shouldn't be followed up by
a more detailed description. "git log --oneline" displays only the commit
header.

~~~
Joeboy
Maybe you're mostly referring to some more complex use of --oneline, but to me
that seems like more of an argument for _not_ editing useful information out
of your subject line to fit the character limit. Of course all other things
being equal, a short subject line is preferable to a long one. But if you have
to make a choice, I think it's often better to treat the character limit rule
as a guideline.

I'm sure I've broken this rule many times, and I'm not aware that it's ever
caused a problem.

~~~
jstimpfle
Of course. It's just a guideline. All I've done is given a justification for
the guideline by presenting a common usage scenario (as intended by the
authors).

------
tigershark
I don’t think that this guide is focusing on the important stuff. It’s
advocating really minor things like the capitalisation of the first letter and
the use of the imperative form while it completely ignores the most important
rule for a commit message: Add the Jira id (or whatever issue tracker you are
using) in the commit message. In this way when doing a blame on a file it’s
immediately clear why something has been done in that way, with a in-depth
explanation of the use case just one mouse click away in the issue tracker
system. For me this is much more important than capitalising the first letter
of the commit since it provides an immediate and durable value.

~~~
swalladge
> most important rule for a commit message: Add the Jira id (or whatever issue
> tracker you are using) in the commit message.

I think it's worth noting that the actual text in a commit message stays with
the repository. The contents of an issue referenced by the id does not. This
is something to be considered especially if this is for an open source project
or otherwise somewhere where the git repository itself is more
important/central than the issue tracker platform.

~~~
tigershark
Obviously it’s a possibility, but in my experience, in the several jobs that I
had in my life I experienced 1 or 2 source control migration in pretty much
each of the places that I have been, and a grand total of ZERO issue tracker
software change between all of them. It’s obviously anecdotal but pretty much
everyone is migrating to git, changing issue tracker is something that you
experience much less. And even if it happens a proper migration would preserve
the ids, so nothing is lost if it’s done correctly.

------
city41
I think the most important thing is to create atomic commits. Each commit
should do one thing and do it cleanly. In other words, if you later regret the
change, you should only have to revert one commit to remove it. If when
reverting you need to go back and reapply part of the commit (due to it being
unrelated), that's the sign of a bad commit.

I've worked with people who were adamant white space and formatting changes
should always be in their own commit. But in my experience, it's never been a
problem.

~~~
Negitivefrags
When you are trying to merge a commit to a branch, and it wont merge cleanly
because of some trivial white space change someone made in an unrelated
commit, you will understand why people dislike it.

It's a pain in the ass. At least if the whitespace / formatting changes are in
their own commit, then you can just merge that one first and continue on with
your day, rather than having to manually resolve the merge problem potentially
leading to more merging problems down the road.

~~~
speedplane
Wouldn't it be nice if git had an understanding of what was being committed,
and could identify white-space/formatting changes versuses substantive
changes? I suspect it could automatically fix these types of common issues.

~~~
jnurmine
Then Git would have to be content-aware, as sometimes whitespace is meaningful
and sometimes just formatting.

Add different ways to format code in, say, C, C++, Java, and so on, and you'd
add a whole lot of unnecessary complexity into a version control software...

~~~
Gibbon1
I've dealt with tracking schematic capture and layout software. And just a
infinitesimal amount of database stuff. The difference I note is that software
version control systems are hopelessly broken because they work on text and
not structured data.

With a schematic you can reorganize a schematic and then compare the netlist
and parts and if they are different you broke something. You can generate
meaningful descriptions of of changes. Changed all the parts of this type to
that type. Renamed these parts to these new names.

Problem is no one designs languages to be able to do that.

~~~
marcinzm
The problem is that to properly understand the structure of the code you need
to load in all dependencies of the code (both in other files and imported
third party modules). That's time consuming and has to be done somewhere.

As a note, in Scala, scalameta will do just that and then dump out a
structured view (in a specified protobuf format) of your code which you can
work with.

~~~
Gibbon1
That why I said a problem is languages aren't designed with that in mind. I
think C# is pretty close since it was written with debugging as first class
feature. But to really get the benefit you need a language that's tightly
coupled to refactoring tools. And that means giving up on Unicode text as the
file format.

There are other problems, anything more than naively comparing and diffing
AST's is a hard problem. I've also seen some really bad things with editing
non text data. Like the file you've been editing for a few days is corrupted.

~~~
int_19h
There's nothing wrong with Unicode text as a serialization format, so long as
all your diff tools operate on the deserialized graph. I mean, when you do a
diff on a database, do you care about the binary format of its files on disk?

And I don't see why you can't do this sort of thing with most languages that
we already had. Indeed, this immediately reminded me of structured code search
in IntelliJ IDEA, which has been around since early 00s. What's special about
C# in that regard?

~~~
Gibbon1
> What's special about C# in that regard?

Not unique but far as I understand you can parse a C# module without knowing
anything about it's dependencies.

> There's nothing wrong with Unicode text as a serialization format, so long
> as all your diff tools operate on the deserialized graph.

The point is you need to actually edit the de-serialized graph not the Unicode
expression of program. Changes to the code aren't expressed as changed to the
text, they're expressed as changes to the graph.

AKA diff is object foo nenamed object baz. And that's it.

~~~
int_19h
Most languages can be parsed without knowing dependencies of a translation
unit. I would say that something like C and C++ (where you need to know if
something is a type or not in many contexts) is an exception to that rule.

And you don't have to _edit_ the graph. You can still edit the serialized
representation directly. So long as you _diff_ the graph, how the changes were
made doesn't matter. For example, there already are XML and JSON diff tools
that do advanced structural diffing, and they don't care how that XML or JSON
was edited.

------
interfixus
This is strictly my own idiosyncrasy, I know, but it has stubbornly refused my
many attempts to change it over the years: I cannot get used to the
imperative. _Do this_ or _do that_ always signals some pending issue,
something yet having to be _done_. Whereas a message saying _did this_ or _did
that_ tells me exactly what I need to know, namely what the commit was about
in the first place.

But then, my linguistic instincts are probably all slightly off: I have so far
never gotten used to _pull request_ not meaning ' _kindly asking permission to
download some code from your repo_ '. I really feel Linus should have
consulted me on that one.

~~~
Joky
Past-tense is about the what the programmer did to get to the patch, present
(imperative...) tense to me is describing in the absolute what is a diff is
doing (it describes the act of `git am` this patch).

While the past tense makes sense from the author point of view describing what
just happened until they typed `git commit`, I'm in the "present" camp since I
find it more relevant to me when reading `git show <rev>`: it tells me what
the _commit_ is doing at this particular point in history. I don't really care
about the programmer/author centric point of view at the time the message was
written.

~~~
brianpan
Past tense is not necessarily programmer-centric. Release notes are generally
written in the past tense (with headings like Added/Changed/Removed). If
commits are written in the past tense and from the user's point of view they
can be used pretty directly to create the release notes.

> it tells me what the commit is doing at this particular point in history

When I talk about a particular point in _history_, I use past tense. :)

~~~
Ace17
> Past tense is not necessarily programmer-centric. Release notes are
> generally written in the past tense (with headings like
> Added/Changed/Removed).

... which makes past-tense release notes "team-centric". In other words, past-
tense release notes are about justifying the work that was done (like some
kind of work report), rather than being an exhaustive list of changes in the
application behavior brought by a new version.

> If commits are written in the past tense and from the user's point of view
> they can be used pretty directly to create the release notes.

Bad idea IMHO.

Making developers worry about their commit messages potentially being used
"pretty directly" as release note lines seems dangerous:

\- It implicitly convey the idea that commits and release note lines should
have the same granularity. This might be true in some cases for programming
error fixes, but it's generally not for features.

\- What about confidential stuff? commit messages are going to get a lot less
informative if there's technically relevant stuff that programmers can't
mention anymore (like the names of other customers, the yet-to-be-announced
next product, etc.).

~~~
brianpan
Why do you think release notes are "team-centric"? Who do you think release
notes are for?

[https://www.mozilla.org/en-
US/firefox/66.0/releasenotes/](https://www.mozilla.org/en-
US/firefox/66.0/releasenotes/)

------
pinjasaur
I find commits very relevant when grokking unfamiliar codebases. The history
and changes (plus, how they're documented) are half the battle for me in that
context.

The article mentions the use of line-length and commit-templates. Personally,
I have my .vimrc [0] configured to handle columns for commits (50 for the
title & 72 for the body). Then, in my .gitconfig [1] I set a template [2] to
be used for all commits. It's a relatively minimal addition, but it's improved
my CLI experience with Git immensely.

[0]:
[https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.vimrc#L89-L99)

[1]:
[https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.gitconfig#L71)

[2]:
[https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.gitmessage)

Edit: fix link formatting

~~~
Gibbon1
Yes! Someone unfamiliar[1] with the code-base should be able to make basic
sense of what was done and why.

[1] Like my boss tomorrow. Or me in 6 months.

------
wirrbel
I don't know how people are programming. I have good unit tests and regression
tests and even though I commit frequently, most of the time I don't end up
with single purpose commits and usually when I trace back commit history these
single purpose commits don't help me much, even if the team mates were writing
commit messages like these.

How much time do people spend to put too changes they did almost at once to
make the code compile or the tests pass into two commits?

Much more valuable are larger commits at the size of a small PR.

~~~
MrBuddyCasino
I don’t understand why the history of the code matters so much to some people.
Give me well designed and commented (!) code, with tests, designed to be
understood by humans. Thats a bar few code bases clear, if I need to look at
the git history its a sign the code is crap and I have to use all the
information that I can get, with history being my least favorite because it
has shitty UX (discoverability, navigation).

~~~
int_19h
As time passes, practically no actively maintained codebase is going to clear
your bar. It's going to pass through several different teams, with different
policies and standards. Eventually, parts of it are going to be put on life
support, which generally means an understaffed team that scrambles to patch up
the most egregious bugs, often with dirty hacks, because they have no time and
resources to do massive rewrites that are necessary to fix things properly.
Maintaining such codebases requires a lot of "code archeology", and good
history makes it much, much easier.

~~~
MrBuddyCasino
Not sure I get your point. People will cut corners and mess up the code, but
somehow the history could be excempt from this?

------
kabdib
Gahhh. Ignore most of that stuff about language, it doesn't add much value.

Just use common sense: Be clear, be informative, don't waste people's time.
You're not writing deathless prose or trying to craft the Greatest Commit
Comment of All Time. The Grammar Police are not going to break down your door
with their milspec copies of Strunk and White and put you up on charges.

One thing I try to do is be a little entertaining. Just little things, a twist
of a phrase or something that might cause a commit to stick in someone's head
for a while. I've had comments like "Best commit logs of the project," so at
least people were looking forward to reading them. Which, if you are
scientific and dry and oh-so-grammarly-correct, they won't be.

I've had people mention some source-code comments I'd made a decade or two
earlier (e.g., in public headers). That was fun.

------
perlwle
I have been recommending this article to my teammates:

[http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git-
commit/)

~~~
swalladge
Agreed. This is by far the best guidelines for git commit messages I'v found.

------
indentit
I personally don't like hard wrapping the body of a commit message because it
then looks terrible every where - GitHub website, git client etc. and it
becomes much harder to read

~~~
jklm
That’s interesting, IIRC short lines are supposed to increase readability
because longer ones are harder to mentally wrap.

~~~
ceejayoz
Sure, but there’s no reason that has to be done manually. Leave it to the
client.

~~~
yawaramin
Most clients don't wrap in a way that helps readability, though. Look at
Hacker News comments for example. At 1:1 zoom the text is spread out across
the screen in super-wide lines that are hard to read. The classic recommended
72-char hard wrap guarantees a good reading experience on all but the
narrowest of screens.

~~~
Reelin
I often browser HN in a half width window for this exact reason. To be clear,
I don't fault HN for this; I can trivially resize my window to whatever works
best for me. Commit messages are different because people often interact with
them via command line based tooling.

------
sirsuki
Look, the simple matter is that commit messages are designed from the bottom
up to be a medium of prose in the same way email is. I would venture to guess
that an email written with good grammar, capitalizes subject (that is less
then 50 characters), and a articulated thoughts would ecstatically welcomed
compared to the drivel we normally recieve. Commit messages are no different.
If one feels that a one liner is sufficient to establish context because the
code is so impeccable then that is nothing short of arrogance.

Think of commits like little emails. They have a subject that should fit in a
subject cell of a table. They have a body. And they have attachments (the
diffs).

Why wrap lines? Because it is text. If you feel every client ever created
handles wrapping appropriately then I’d ask to move the rock you’ve been
under. For 30 years I’ve watched client after client screw up text wrapping.
Heck, just sample a few government websites. By claiming commit messages are
text you are taking back control of the crazy cesspool that is the modern app
era and crafting a prose and typesetting fit for your own high standards.

As Steve Jobs once quoted: “Be a yard stick of quality. Some people aren't
used to an environment where excellence is expected.“

~~~
u801e
> Think of commits like little emails. They have a subject that should fit in
> a subject cell of a table. They have a body. And they have attachments (the
> diffs).

In fact, git has a command[1] to convert your commits to email messages.

[1] [https://git-scm.com/docs/git-format-patch](https://git-scm.com/docs/git-
format-patch)

------
aizatto
I have my own notes here: [https://www.aizatto.com/engineering-code/commit-
messages](https://www.aizatto.com/engineering-code/commit-messages)

I think what I really like Angular's Commit Message Guidelines that suggest
you include a "type" (build, docs, feature, fix, refactor) prefix into the
commit message to help organize at a quick glance what the commit does.

[https://github.com/angular/angular/blob/master/CONTRIBUTING....](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit)

Here are some other resources

Erlang [https://github.com/erlang/otp/wiki/Writing-good-commit-
messa...](https://github.com/erlang/otp/wiki/Writing-good-commit-messages)

Gerrit
[https://www.mediawiki.org/wiki/Gerrit/Commit_message_guideli...](https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines)

~~~
regularfry
I can see the value in gerrit's suggestion of including the component name in
the header. I'm not sure I see the value in adding the commit type. Where do
you see it as useful?

------
callmekatootie
The best advice that I got came from CodeSchool's github course (this was
about 5 years back so I am not sure if they have updated it). It said that the
commit message should indicate what will happen if that commit is applied by
another user, not what changes have been carried out. It's worked well for me
so far.

------
bloak
I think the form being used is "infinitive" rather than "imperative". The
forms are identical in English, so it's hard to be sure, but in other European
languages it would be the infinitive, I think, so I would guess that it's the
infinitive in English, too. Also, it just doesn't seem like a command to me.

The document is translated into two other European languages, but the examples
are still in English, which is a shame. A translator who is keen to go the
extra mile would provide the examples in English and the target language, in
my opinion.

------
fideloper
The value of git is the tooling around pushing code to a central place.
Version control is a relatively minor (albeit occasionally very helpful) part
of the value of git.

I’d argue that central storage (somewhat ironically), open source support, CI
automations (esp. web hooks), issue management, etc offer far more value.

In other words, GitHub (and friends) are the value worth spending time in,
rather than being in the weeds of using Git “perfectly”.

------
woile
I prefer conventional commits, I have created a tool that prompts some info to
make it easier to remember, I can also bump automatically the version using
the commits. I've been using it with friends with no issues. I really like how
the commit log looks

[https://github.com/Woile/commitizen](https://github.com/Woile/commitizen)

~~~
regularfry
I've seen real problems with using commitizen. The first, and probably most
insidious, is that if you've got a tool to enforce a format, people stop
thinking about the content, but still believe they're getting good commit
messages because the tool tells them so. This makes it harder to convince them
that content quality needs addressing. Worse, it gives you no flexibility to
use the limited space in the commit header if you, the human, have a better
idea of what the commit message should be than the tool has.

It breaks muscle memory. For me, `git commit` is something that happens
frequently - on the order of several times an hour, and not necessarily only
in a single project. If the steps to commit are different from project to
project, that's a mental speedbump every time I make a change, which pulls me
out of flow and distracts me from whatever it is I'm doing. This is made worse
when the commit format rules are in flux, because I then get tripped up within
a single project.

Lastly, it's Yet Another Thing That Can Break(TM), and a specific example of
that pernicious class of Technical Solutions To Human Problems.

~~~
woile
Hey I'm sorry you had problems with it. I myself don't use it always. My main
idea is to make it easier for teams to share the commit conventions with new
developers (at work, for example, there was other convention which I find it
hard, so I made a plugin also for it). Sometimes I'm not sure what type of
change it is, so I can trigger `cz commit` and the prompt helps me remember
what is what and to choose a proper prefix. My main objective was to avoid
writing lazy commits 'fixed api', which I've seen around.

You don't need to use commitizen to write the commit, if you want you can
choose conventional commits and write directly git commit, or use nothing. But
if you use conventional commits, later you can use `cz bump` and detect the
type of increment, and there are already tools that help you create a
changelog as well.

I'm using this stuff with some friends in a project we are working on, and we
use conventional commits (whoever wants uses commitizen) for our git messages,
and then after a PR is merged into master we can execute `cz bump` in our CI
and we have a new relese ready to deploy.

------
darth_mastah
What's wrong with Angular commit message guidelines?

[https://github.com/angular/angular/blob/master/CONTRIBUTING....](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-
message-guidelines)

~~~
tomxor
Nothing - in the context of angular project, which this is not. They are not
general enough, everything isn't angular.

But if you want to compare, I also dislike how they choose to expand the line
width to arbitrarily accommodate certain git web uis but shun minimum terminal
widths.

~~~
marcinzm
Shouldn't your terminal view be able to wrap the text itself before showing it
to you? That seems a UI display issue rather than one to solve by changing the
underlying data representation. I understand why that's not good with code but
commits are almost always non-code.

~~~
tomxor
You know what, that's a fair point, but it's also just not how it works...

The reason for the 72 rule is that minimum terminal columns (since the
beginning of time) is 80. git-log will pad the message with a 4 space margin,
so to keep it centred you want it to be 72... alternatively to keep it from
sprawling to illegible lengths you want to hard wrap it at about that width
anyway.

So you will find one of 2 undesirable things happen if you don't hard wrap to
this length:

1\. Your terminal or pager _will_ wrap the text, but knows nothing of the
formatting, so it will wrap onto the next lines without indentation (this does
reduce legibility, making it harder to see where one commit ends and another
begins in the full log).

2\. Your terminal or pager _wont_ wrap, in which case have fun scrolling to
the right - a lot.

You could rightly argue that if the terminal + cli + pager and git were one
monolithic UI, then it would have a more holistic view of whats going on and
smarter decisions could be made - but then we lose all the benefits of those
separations (the unix way). There is no win win, but it is at least pretty
trivial to hard wrap text automatically in your editor.

------
avodonosov
Subversion recommened commit messages to be single line, without breaks. The
argument was that it's good for scripting, the one record = one line approach
usual for unix scripts.

I have this habit since then and format all my git commits that way, despite
the multi-line tradition in git.

Was Subversion wrong?

------
sbmthakur
I read the following tutorial on the topic few years ago and it has really
helped me with commit messages:

[https://chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-
commit/)

------
1wd
This guide is strange. The order of rules is in no relation to their
importance: Imperative, Capitalize, Self-contained, Explain, Avoid "stuff",
Length limit, Consistency.

That's like a health guide listing: Circumcision, Limit coffee, Exercise,
Vitamins, Avoid "Russian roulette", Vaccination, Brush teeth.

------
anonytrary
Author suggests using imperative form commit messages ("add X") as opposed to
past tense ("added X"). Past tense should be avoided, but using imperative
form sounds unnatural and incomplete. I prefer present tense. Just follow this
template and you'll be fine:

    
    
      Q: What does the commit do?
      A: The commit <commit>.
    

Example:

    
    
      Q: What does the commit do?
      A: The commit adds extra padding to the header.
    

In this example, "adds extra padding to the header" is your commit message.

~~~
intertextuality
Both are natural, but imperative is simply more commonly used.

 _When applied_ , this commit will <refactor abc controller>.

This commit <refactors abc controller>.

I personally prefer imperative because when you look at a commit it hasn't
necessarily been applied yet. But it's like arguing about the difference of
potato and potato. As long as you're consistent (and write good messages in
whatever style) it doesn't really matter.

------
z3t4
When I look at commit messages its to know why the ____and who the __ __.
Note. Its still OK to leave comments.

------
vojta_letal
I do not like the idea of giving anyone access to my email account. I'd rather
see a desktop version of an inbox-clone.

~~~
melansoncholia
Pssst...

[https://news.ycombinator.com/item?id=19705440](https://news.ycombinator.com/item?id=19705440)

