
Commit messages are not titles - cocoflunchy
http://antirez.com/news/90
======
stared
Dots, periods or starting with caps - it makes no difference (except for
aesthetics, perhaps.) What does (or at least: did for me) is Angular-style
commit messages:
[https://github.com/angular/angular.js/blob/master/CONTRIBUTI...](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).

> <type>(<scope>): <subject>

> [...]

> feat: A new feature

> fix: A bug fix

> docs: Documentation only changes

> style: Changes that do not affect the meaning of the code (white-space,
> formatting, missing semi-colons, etc)

> refactor: A code change that neither fixes a bug or adds a feature

> perf: A code change that improves performance

> test: Adding missing tests

> chore: Changes to the build process or auxiliary tools and libraries such as
> documentation generation

There is a big difference in knowing if someone added a feature, fixed
something, or did some refactoring.

~~~
braythwayt
Whenever I see a convention like this, I think to myself, “There is another
data model being serialized into text.”

~~~
stared
Not exactly. The actual commit content is in the code difference. Code message
is just some kind of human-readable abstract, or at least - a hit of what was
changed.

There is a big deal of subjectivity (e.g. what is a bug, and what is a
feature) but (as with any comments in the code) it is nice to see at least
what was intended (e.g. someone wanted to position a misaligned button, or
added it, or improved its visuals or optimized its click from O(n!) to O(1),
...).

~~~
icebraining
The code message is metadata, like the commit hash, date and author. It could
easily be split up into different fields.

------
kashyapc
Speaking of Git commit messages, it's worth pointing out this wiki[1], written
and reviewed by some long time open source contributors. It's a bit verbose,
but rewarding to the patient reader.

On writing Git commit subject lines, I've come to appreciate why the
imperative mood is nicer (as opposed to the and indicative mood). Some related
reasoning here[2].

[1]
[https://wiki.openstack.org/wiki/GitCommitMessages](https://wiki.openstack.org/wiki/GitCommitMessages)
[2] [http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git-
commit/)

~~~
js2

      Add comment strongly agreeing with parent
    
      The links in the parent comment are to documents which are
      prescriptive, based on hard-earned experience, and provide
      well-reasoned justifications for how and why to format commit
      messages, along with examples of projects which do so.
    
      I wish the parent comment were at the top of the page, but I can
      provide only a single upvote. This comment is to provide more
      exposure than an upvote alone, and so that I can find it my HN
      history.

~~~
gkya
\- [http://orgmode.org/](http://orgmode.org/) (or Evernote, this-pad, that-
pad...)

\-
[https://en.wikipedia.org/wiki/Bookmark_%28World_Wide_Web%29](https://en.wikipedia.org/wiki/Bookmark_%28World_Wide_Web%29)

\- Direct link to parent comment:
[https://news.ycombinator.com/item?id=9764039](https://news.ycombinator.com/item?id=9764039)

------
BillinghamJ
Does anyone actually care whether commit messages contain a period or not? If
they're lower case, title case, sentence case, it's completely irrelevant

~~~
richmarr
Sadly. In my view they're bikeshedding, hard.

~~~
gutnor
Bikeshedding like this is useful as a team efficiency metric.

If you can't get quickly to an agreement about such a thing, or if the members
of the team that didn't get their way actively rebel (or worse sabotage), you
are working with a team of divas.

(note: of course developers whinge, as long as you stick with the team
decisions once their are made, whinge all you want)

~~~
falcolas
> If you can't get quickly to an agreement about such a thing ... you are
> working with a team of divas.

Or you're working on such a trivial problem that it should have been given to
an individual, not a team.

~~~
gutnor
Well that's the point. Feed the team with a trivial problem to see how they
react.

A well working team will probably do as you say - volunteer an individual to
write the rule in an email and follow it from there on.

If you going to introduce changes in a team, like for example introducing
Agile (the proper way) or you are starting a new project, you want to quickly
gauge the team dynamic, and that's a good exercise.

------
knocte
As for me, I don't care about the style at all.

What I care is about the content. And the thing I hate the most are commit
messages that explain the _what_ , but not the _why_! (It's the equivalent to
comments in the code that explain something obvious.) To me, this kind of
commit messages express the same as if there was no commit message.

~~~
callum85
But if the commit message says what happened, then you don't need to read
diffs to find out what happened. Reading an English sentence is easier than
reading code diffs, and also you can read a bunch of sentences in list form
(eg, git log).

I'm not saying you don't need to include the 'why', I'm saying there is value
just in the 'what'.

As for code comments that just 'explain something obvious'... I have no
problem with comments that simply summarise, in English, what the next few
lines do. It means I can skim through a file just reading the comments, until
I find the part I want to debug/modify/understand in more detail. Also, if you
can sum up some code with a sentence then there's a good chance it makes
sense, so it's a good quality check.

~~~
knocte
With the 'what' of course I don't mean 'what happened', as the latter would be
actually kind of the 'why' you're making the change. So with the 'what' I mean
'what is being changed', some people just write what file are changing and
what they are adding to it, explaining how the code is changing in the diff,
but not _why_ the code is changing.

As for code comments, I think you're basically wrong. If you can summarize
some fragment of code under a sentence, extract that piece of code into a
method and name that method in the same way you were going to write that
comment; otherwise comments get outdated easily. These kind of techniques are
well explained in a very good book I read a while ago, it's called "Clean
Code".

~~~
dspillett
I have no objection to summary comments - they can guard against certain types
of accidental or otherwise erroneous edits. If the code and the comment don't
quite agree then suspect both of them are wrong.

Personally I think check-in comments should be a concise (but not generic like
"bug fix") description of "what" with a smattering of "why" (perhaps a
reference to a bug/ticket/feature/request ID). The details of "what" can be
seen by looking at the diffs. Where the details of "why" go is split. Why you
chose a particular method over others available? Any constants or magic
numbers you think might need clarifying when someone else looks? You've done
something that looks odd/unnecessary at first glance in order to work around a
bug/limitation beyond your immediate control? Those things go in comments in
the code. Just about everything else goes in the ticket and possibly makes its
way to other documentation, there is not point cluttering the code up too much
(unless your implementation documentation is all in-code and you use tools to
extract it into other forms, as I've seen done before now, in whic case
everything goes in there). "FIXME" and "TODO" markers can go in the code too
though generally you want them gone for release (if they survive between
releases then they should really be feature requests in your backlog rather
than just code markers, so they can be tracked/managed/prioritised as needed.

What really grinds my gears is commits without any comment at all.

~~~
ajuc
> What really grinds my gears is commits without any comment at all.

That just shouldn't be allowed. Commits without JIRA (or whatever you use)
task reference should just be automaticaly rejected.

~~~
dspillett
Yeah, the legacy project I'm working on isn't that modern... And even when
rules are enforced, people sometimes work around them and leave a useless
commit comment. Lax documentation, sometimes deliberately lax, is a person
problem unfortuntely - one better solved in ways that HR would disaprove of
then via technical blocks!

------
strictfp
Oh god, another commit message discussion.

It's funny how the ones who contribute the least to the functionality have the
most outspoken opinions on commit messages. Perhaps it's easier to be puritan
when you only handle trivial code changes.

I prefer productive people with messy commit messages over pedantic people
with meticolous commit messages any day.

The picky ones usually refuse to touch anything surrounding their particular
feature and end up increasing code complexity with every commit, whereas the
productive people massage the code into the best possible state as they go
along.

~~~
ionforce
I don't understand how you could possibly tolerate messy commit messages. It's
as if you've never had to do a code investigation/audit ever, heaven forbid
you do.

~~~
GrinningFool
I don't think that's a fair statement, at least based on my own experience.
When I'm investigating how code arrived at a certain state, I'm looking
primarily at the code.

The commit messages are nice as indicators of intent, but I don't rely on
them. The real change is in the code, not what somebody remembered to write in
a summary of the change.

~~~
ionforce
Investigating code deltas tells you nothing about HOW the code got there. It's
there. Someone committed it. But WHY? Hence, the commit message.

"new feature. fix it. fixed. lol. WIP. COMPILES NOW"

None of these tell you how the commits came to be other than that they are
already there.

------
buster
Regardless of my opinion about this subject, i always find it good to see when
people try to think out of the box. Nowadays most people just follow what is
the current hype:

yeah, let's do semver! And it HAS TO BE react, agile and also it must be in
Git, because... yeah, because what? Did you as a developer _really_ think why
you are following a certain practice and if it is beneficial to your project
at hand? Most people don't. They just do what John Doe posts on his hipster
blog about Web3.0.

~~~
minot
If you join a team project, you have to follow the team convention. It is not
necessary to put dbo. in front of table names in SQL server. Yes, you can use
.PHP instead of .INC for class files. No, C# will compile just fine if you
indent with four spaces or eight spaces instead of a tab.

However, when you are working in a team, you follow the convention of the
team. Or change the convention so the team is on the same page.

~~~
hobs
>It is not necessary to put dbo. in front of table names in SQL server.

Depending on default schema, it definitely can have performance considerations
on compilation.

Maybe some of those team conventions are actually based on real world things.

From: [https://msdn.microsoft.com/en-
us/library/dd283095%28v=sql.10...](https://msdn.microsoft.com/en-
us/library/dd283095%28v=sql.100%29.aspx)

SELECT * FROM Table1

Will assess the following statement first: SELECT * FROM
<defaultschema>.Table1

If it cannot find the object, the server will assess the following statement:
SELECT * FROM dbo.Table1.

The assessment process can be improved by using either the fully qualified
name or the DEFAULT_SCHEMA option described earlier. By setting a value for
DEFAULT_SCHEMA for the user, the server will check the DEFAULT_SCHEMA first,
removing an unnecessary ownership checking process. This can improve
performance considerably on heavily utilized systems.

------
chrisan
I really like bitbucket and JIRA for this in a business use case.

We use the format "JIRA-XXX commit message/title/synopsis/whatever you wish to
call it" where JIRA is our project name in JIRA and XXX is the ticket number.
Bitbucket then can turn that into a link to your JIRA project

All of the who/what/why is already in the JIRA ticket as more often than not
there are non-coders who have input/insight around the issue. When I am
looking at the commit log I see a brief summary and if I need more details I
can go to JIRA and get the full history with screenshots, designs,
reproducible steps, business cases, etc.

Another side effect of this is, when someone is searching in JIRA and finds a
ticket they can easily see all of the commits related to that ticket. This
also works with Github

The commit becomes simply the "how" "JIRA-XXX brief desc" was implemented

~~~
ascagnel_
The issue with this is that, over the course of development, the comments on a
given JIRA ticket will start to cover QA and release steps, and they drive
down the signal-to-noise ratio.

~~~
ajuc
Never had problem with this. Usually people add separate linked task for
release (and specification).

------
emodendroket
Way too much energy to expend on worrying about this.

I put Github issue numbers into my commits because I use Github. Anything is
fine if you're consistent.

------
VeejayRampay
The first comment under the post is frankly outrageous.

This is precisely the reason why the rest of the world abhors programmers and
the software community. Random strangers contributing nothing to the debate
but their angry and immature bile. No wonder content creators are disabling
comments one after another, why wouldn't you?

~~~
jeremiep
Well, programming can be picked up by just about anyone these days, so its no
wonders you get people as mature as youtube commenters in the mix.

This is what differentiate professionals from amateurs.

------
nandemo
In a previous gig, we had a simple rule: there must be a ticket number with a
certain format at the beginning of the commit message. A summary follows.

The ticket has pretty much all the info you need, so there's usually no need
to write a very detailed commit message.

This essentially mandates tickets for every single commit, which might sound
too process heavy for some people, but ticketing was part of our process
anyway for other reasons (change management, compliance, etc).

In the rare event that a commit is not originated by a ticket, you can still
cheat by writing a fake ticket number.

~~~
dsr_
It ought to be a simple matter to start a new ticket and dump your work into
it.

A la the Joel Test, your ticketing system should:

\- open a new ticket on receipt of unknown email, sending back the ticket
number

\- treat email with a proper subject prefix as a comment on an existing
ticket, adding any attached files

\- easily merge two or more tickets, preserving both histories and redirecting
all references to the old tickets to the new one

\- maintain metadata and ACLs for metadata

\- automatically re-open a ticket when a new comment or reply is received

\- require a message to close a ticket

\- provide summaries

\- be full-text searchable

\- track all history immutably

\- provide a method to associate many individual reports of the same problem

------
StavrosK
I was recently advised to use the "commit messages are subjects" style, but I
get a pang of... something, every time I have to omit the full stop (I always
type it out of habit and then press backspace).

I agree completely with Antirez, messages are not subjects or titles, and we
should make them as succinct as possible, not force ourselves to write
something that leads into a full-text piece only to omit the latter.

If it can fit in one line, make it fit, otherwise summarize the change as well
as you can. Our goal should be to have to read the least amount of text to
understand what the change is doing, and the hierarchy is: short commit
message > long commit message > diff.

~~~
WalterGR

        I get a pang of... something, every time I have to omit the full stop 
    

Good. :) One thing that's very nice about the full stop:

You know that you've read to the end of something.

In the absence of one, there's always the chance that text has been cut off

~~~
StavrosK
Cut off what? The suspense is killing me!

------
teh_klev
> How many emails or articles you see with just the subject or the title? Very
> little, I guess

I hate to go OT and "well actually", but, _well actually_ this is more common
that you'd think. I first learned about "subject only" emails back in 1998 and
most places I've worked at use them to convey succinct email messages where
there's no need for extraneous words in the body. It's a real time saver when
you have a busy inbox.

I've also worked in places that "EOM" (or some variant of) their message
subjects to be explicit that there's nothing in the body [0].

WRT to the remainder of the article, I don't have any strong feelings either
way.

[0]: [http://lifehacker.com/5028808/how-eom-makes-your-email-
more-...](http://lifehacker.com/5028808/how-eom-makes-your-email-more-
efficient)

~~~
SixSigma
NT

------
sambe
I also prefer treating them as sentences and prickle at the level of
enthusiasm for no dots. In the end consistency with others is more valuable
though. However, the article is entirely unconvincing to me, despite being on
his side - the removal of a dot and writing succinctly are not mutually
exclusive.

------
przemoc
It always felt natural to put this dot at the end of (what antirez nicely
called) commit synopsis, so AFAIR I always (or at least since I started using
git and when was not forced by particular project's rules to do some other
way) put it there and found advices to avoid it quite strange. The only
exception (beside forgetting about full stop yet pushing to public repo, it
does happen sometimes) I have is when the commit is sole version-
bumping/releasing one, because then I usually go with following style

    
    
        PROJECT_NAME [v]VERSION
    

There are some half-broken SCM managers that always display whole commit
message (sometimes even without respecting paragraphs) and then such synopsis
without full stop yet followed by another sentences looks rather awful. YMMV

As some commenters here already wrote, it's not a grave matter, but it's good
to have consistent style. It goes without saying, that having relatively short
commit summary in one sentence separated with blank line from further details
(if they are necessary) is far more important matter than the period or lack
thereof, as it immensely eases groking commit log.

------
callmekatootie
Commit messages need to convey what _will_ happen if you merge that commit in.
Plain and simple. That's all that is needed of them. Of course, you need to
tag the ticket number (in case you are using Cloud based solutions like
Github) but I am more interested in what the changes will do if I merge them
in.

------
jgrahamc
I think the body of the commit message is way more important than the title:
[http://blog.jgc.org/2013/07/write-good-commit-
messages.html](http://blog.jgc.org/2013/07/write-good-commit-messages.html)

~~~
antirez
Body is super important, but when you can craft a very good single line commit
message, is not bad either. It is hard to find a balance but what I try to do
is to reserve multi line commit messages for situations where it is
appropriate to provide mode details compared to just "git show" the commit to
check the actual content.

------
anton_gogolev
Is it me or the entire "Kosher Commit Messages" movement really gained
traction with the widespread adoption of DVCSes?

I really cannot recall contributors obsessing that much over SVN, CVS or VSS
commit messages. Now, you could change these after the fact, but still.

~~~
zelos
We used to have a Perforce changelist guideline newsletter here.

No, I'm not kidding.

------
zvrba
How about: if your message doesn't fit into a single sentence, the commit is
too big. Split it. If it's a huge architectural change merged from another
branch, describe it in a separate document referenced in the message.

------
tempodox
It seems obvious that inside any given organisation, it makes sense to have a
convention regarding the form of commit messages, so you know how to look for
certain things.

However, pretending there is a one-size-fits-all rule is taking it too far.

------
maxehmookau
I'm waiting for the 'Commit messages considered harmful' blog post.

------
hasteur
While I commend the poster's ideals, the method only works in the glass
cathedrals model of development. One in which no commit gets made without
having followed the process from inception, through requirements gathering,
through unpressured development, through appropriate and thorough QA/code
review, and deployment. In the street market bazzar you're left with thousands
of micro commits that you don't have time to sit down and create an
illuminated manuscript page for each commit explaining it's small description,
and it's naritive history.

------
m0skit0
We use Redmine and just put the relevant issue number and the title of the
issue. If more information is needed, you can go to Redmine to check more
details or how to reproduce.

~~~
pdpi
I prefer the next step over: Branch is named after the ticket and a short
description of what the branch does, commit messages just talk about the
contents of the commit itself.

~~~
m0skit0
We actually don't make a branch for each ticket because we need to expose the
repositories to outside and so we use Gitolite, and having to reconfigure
branch permissions each time... Ain't nobody got time for that.

------
VieElm
The 50 character limit on the first line of a commit message really bugs me. I
try to stay within 50 characters but sometimes I don't care. I can't always
fit what I want in 50 chars and adding a second line can be too much. This is
the worst kind of thing around tooling, these types of conventions, in this
case because that's how Torvald's wants kernel git commits formatted. I am not
committing to anything Torvald's cares about.

~~~
jsmthrowaway
The 50 character convention has nothing to do with Linus Torvalds.

~~~
brazzledazzle
I've seen a lot of posts and comments about the 50 character convention but
I'm not sure I've ever seen a reason for that specific number. What _is_ the
reason for that anyway?

~~~
mikekchar
It appears to originate with Tim Pope: [http://tbaggery.com/2008/04/19/a-note-
about-git-commit-messa...](http://tbaggery.com/2008/04/19/a-note-about-git-
commit-messages.html)

Reading between the lines, it seems that the 50 character limit is to
accommodate commands like "git log --pretty=oneline" and "git rebase
--interactive" on an 80 column terminal. He also recommends 72 columns for any
subsequent text because git makes a left margin of 4 characters and it looks
balanced if you also have a right margin of 4 characters (80 - 8 = 72).

As someone who actually uses an 80 column terminal, I appreciate this
practice. Probably younger people with good eyes won't be able to understand
the reasoning behind it ;-)

~~~
VieElm
> Probably younger people with good eyes won't be able to understand the
> reasoning behind it ;-)

Serious question, have you tried reading glasses? You don't have to just deal
with bad eyes as you age, you can wear reading glasses. This what I do now.

------
overgard
I think people tend to overthink this. The only thing I need from a commit
message is what you did and why you did it. (One might be implicit from the
other). If there's more than that, you might be committing too much at once.
People hardly ever go over commit history unless something got fucked up, and
then those are the things you're interested in. Whenever people get OCD about
the form or rules I cringe.

~~~
JoeAltmaier
As others have observed, these comments are used for auto-documentation, for
reporting, and for merge requests. Its handy to be able to categorize them, to
schedule and organize these activities.

~~~
overgard
I feel like things like "auto documentation" and "automated reporting" are
code words for "things that superficially sound useful that in reality no
human should ever use to make an actual decision". So in that context, well
formed commit messages are very important for supporting bureaucratic
nonsense. My feeling is that if you want to publish a change log, you should
do that by hand while keeping the intended audience in mind, and if you want
to review the performance of people, "metrics" are extremely game-able and
instead the work should be considered as a whole.

~~~
JoeAltmaier
You don't read release notes?

------
silveira
This is what I'm using now:
[http://seesparkbox.com/foundry/semantic_commit_messages](http://seesparkbox.com/foundry/semantic_commit_messages).

chore: add Oyster build script

docs: explain hat wobble

feat: add beta sequence

fix: remove broken confirmation message

refactor: share logic between 4d3d3d3 and flarhgunnstow

style: convert tabs to spaces

test: ensure Tayne retains clothing

------
velco
Right. Commit messages are not titles.

Commit messages ought to consist of a title, followed by an empty line and a
short(-ish) summary.

------
doe88
I think the two most important rules are:

1- The first line should give a good description of the commit

2- Avoid long lines (reading truncated commit messages is painful)

Other than that I think it's all common sense/good judgment and I'm not
attached to a particular writing style or kind of sentences one should make.

------
P4u1
At our company we use a svn hook with Jira, so all commit messages must
contain a valid Jira issue ID which contains a detailed explanation of the
commit itself. So our messages are always like: PROJ-0001 I did this. IMO does
the job and is much easier for the developers.

------
necrodawg
Commit messages are like tabs and spaces. However you write them, keep them
the same across your repository.

But obviously lower case, present tense, no dot, 50 char limit, and usually
starting with add/fix/refactor/update/remove is the way to go. ;)

------
LoSboccacc
Linus on good git comments:
[https://gist.github.com/matthewhudson/1475276](https://gist.github.com/matthewhudson/1475276)

The first line is special for a reason, it makes shortlog clean and clear.

------
scottjad
An option for git or magit that would automatically look at recent commits and
maybe capitalize or add a period to my commit message so that it is consistent
with the majority of the commits for the project would be nice.

Does something like that exist?

~~~
prattmic
I don't know if someone has already written one, but a commit-msg hook could
certainly achieve this.

[http://git-scm.com/docs/githooks](http://git-scm.com/docs/githooks)

------
macu
I perceive the condensed sentence fragment (as requested for Angular) as a
conceptual gist, which is all it really is (a few words to suggest the bigger
picture), not a title (each commit is identified by its hash).

------
fapjacks
I _ALWAYS_ commit message like this:

<action>: <brief explanation>

For example like this:

"refactor: tightened for() loop in networking code"

"added: feature #134"

"removed: debug cruft"

"fixed: one-off bug in string parser"

------
peterwwillis
Fuck it. From now on, all my first lines will be UTF-8 emoji.

------
mkawia
my commits are not only titles they are milestones , I have lolcommits
installed and pose for the selfie and everything.

Could be because of I am new to git

------
jkot
Commit messages could have titles :-)

Most tools only shows first line of message. Rest of the message can contain
whatever you want.

------
nnoitra
What's your blog theme? So cool and minimalistic.

------
jlouis
I have the following in my git config for handling these kinds of discussions:

    
    
        [jlouis@lady-of-pain ~]$ cat .gitconfig | grep phk
    	phk = commit -a -m 'upd'

~~~
erikb
Does phk mean what I think it means? It's definitely funny and I'd definitely
decline all your pull requests, but in company work it really doesn't matter
because most people don't look into the history anyway. So yeah, it's probably
a productivity tip.

~~~
jlouis
It pays eternal homage to a toy-repository by phk in which that commit message
occurs. I found it more fun than `git yolo`. And easier to type as well.

The other reason I have it is that when you are first building up a piece of
software, you may want to snapshot it now and then, but you don't care too
much for the archeology because things are still not working. Once you reach
something which seems to work, you squash everything down and cut your first
release with a meaningful commit.

~~~
erikb
Yeah in a feature branch it's also reasonable. `git yolo` is also nice.

------
Traut
why is this even important?

~~~
ionforce
Because commit messages are important.

------
jsmthrowaway
When using Git's mail features -- remember, not everyone uses GitHub -- the
first line of a commit _is_ a subject line. It's good practice to just think
of it that way. If you write sentences in your subject lines in e-mail, I
guess, that's up to you. Don't take it from me, read the Tim Pope
counterpoint, with eight extremely good reasons for concise subjects in the
closing paragraph:

[http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messa...](http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messages.html)

Strong disagree with antirez on this one. Even vim filetype gitcommit
disagrees. (Try it on the "smart synopsis" example.)

~~~
voyou
I don't see how this is a counterpoint. tpope says "This first line should be
a concise summary of the changes introduced by the commit", and antirez says
the first line should be a "synopsis of the meaning of the change operated by
the commit"; these appear to be exactly the same thing.

But then, I don't understand the distinction the original post seems to be
making between "titles or subjects" and "synopses." A good title or subject
for a git commit _is_ a synopsis of the changes in the commit, in the same way
a good headline for a newspaper article is a synopsis of the article.

------
theVirginian
Why is it that programmers invariably state their opinions as if they were
facts.

~~~
JoeAltmaier
Qualifying an argument weakens it. And makes it less concise. Note: I could
have said "I think that usually qualifying an argument tends to weaken it in
the eyes of the reader". Which is better in a text discussion?

------
seanhunter
How can anyone take the author's word on whether or not to put a full stop at
the end of something when he puts a full stop at the end of the bullet points
in his list? That's far worse usage than anything he's doing in the
title/summary/smart synopsis.
[https://www.oxforddictionaries.com/words/bullet-
points](https://www.oxforddictionaries.com/words/bullet-points)

~~~
phireal
That link you posted says you can put fullstops at the end of lists if the
elements of the list are full sentences.

~~~
seanhunter
"And resulted into this" is a full sentence now? I guess. It's not really
English though.

The whole thing is serious bikeshedding in my opinion.

~~~
Retra
"Sentence" is a highly debated linguistic construct with no clear rules for
what does or doesn't apply. You don't think that's a sentence? So what?

