While I'm not a big fan of altering hg/git status output, because once you start doing this, you can no longer trust in the output, this particular change should not have a noticeable impact on existing muscle memory development patterns, so I'm rather ok with it.

Done, thanks.

What I meant is to exclude .gitignore from the resulting tarballs/zip.
It appears already excluded (by a trailing mask) though, no changes are needed here.

I'm fine regarding addition of "/tmp/":
it consists of intermediate files usually unused after building a release and somewhat unused when building changes. Anyway, underlying files are not intended for "git add".

I'm less confident regarding "/nginx-*.tar.gz":
it represents a rather moving part, also a corresponding zip entry would be missing, and finally, a person making release is assumed to be qualified to know what he is doing. Personally it's convenient to check files produced from "make release" with hg/git status.

To sum up, what I'd expect to see after sorting:

/Makefile
/objs/
/tmp/

Done, thank you.

Also, a period at the end of the sentence please.

Done. I've never seen this notation used in other projects. Could you explain the reasoning behind it?

Done. I've never seen this notation used in other projects. Could you explain the reasoning behind it?

It's just a tradition. Since 2011 all nginx commit messages follow a certain format.

Done. I've never seen this notation used in other projects. Could you explain the reasoning behind it?

It's just a tradition. Since 2011 all nginx commit messages follow a certain format.

We stopped doing that in Unit for the following reasons

• It takes a up a valuable character
• It's not generally a done thing in git commit subject lines (a few early Kernel & Git commits did do it...), one reason I guess is because they are often used as email subject lines, and both of these are not meant to be proper sentences and so do not require a terminating '.'
• Can look messy. Update to version 1.0.1., Fix borkedness in foo.c.

@ac000
nginx have a well established code style and commit log style, please stick to it, thanks.

For more details, you can learn here: http://nginx.org/en/docs/contributing_changes.html

@ac000 nginx have a well established code style and commit log style, please stick to it, thanks.

For more details, you can learn here: http://nginx.org/en/docs/contributing_changes.html

This guide doesn't mention anything about period.