This request seems pretty subjective and completely up to each organization's style guide.
Git natively supports plain text for the commit message, and I think that's all that Sourcetree
should concern itself with.

Well, that's not entirely correct. Please check out what git help commit says:

Though not required, it's a good idea to begin the commit message with a single short 
(less than 50 character)  line summarizing the change, followed by a blank line and then
a more thorough description. The text up to the first blank line in a commit message is
treated as the commit title, and that title is used throughout Git. For example, 
git-format-patch(1) turns a commit into email, and it uses the title on the Subject line
and the rest of the commit in the body.

So the first line of a commit message is special and git will treat it differently in some cases. E.g. check out git help log and go to the PRETTY FORMATS section. Depending on what format you choose, only the first line is displayed by git as this line is considered to be the title of the commit message.

It is just a recommendation, that's true, you are free to ignore it, but it is a recommendation from the developers of git and ignoring it will have negative consequences, e.g. wrong log output or git-format-patch working not as expected or desired. The majority of UI clients and web services that I know stick to that recommendation, github will even warn you when your first line goes beyond the 50 character limit. That's because a lot of tools will by default shorten commit messages in the UI to the first line and this line is then again shorten to 50 characters, if it is longer. If the first 50 characters are no meaningful commit messages, users of these apps will have a hard time browsing through the history as they need to open the detail view for every commit to find out what this commit is really all about.

The 72 character limit on the other hand is nothing that git itself ever mentions, that's just to prevent ugly line breaking in the middle of words if you have a 80 character terminal. And to me it does not sound very meaningful to limit my commit messages to a specific length just because git is too stupid to break on word boundaries. Every other UI tool will do that just fine. Also there is no guarantee that there are no ugly breaks just because I stay below 72 characters as terminals don't have to be 80 characters and when displaying the history in a terminal that is below 72 characters, the ugly line breaks will return. Actually in that case, the limitation to 72 chars leads to even more ugly line breaks than no limitation at all would have, as now there is an ugly break anywhere within the line following a very short line with a manual break and that is even more unpleasing to the eye and even harder to read.

This request seems pretty subjective and completely up to each organization's style guide. Git natively supports plain text for the commit message, and I think that's all that Sourcetree should concern itself with. If at some point in the future Git natively separates summary from details from etc etc etc then i'd say this makes more sense. But that's not the case right now.

However, a valid argument is that sourcetree does not display multi-line commit messages intuitively. In a list view, I can understand the need to turn the entire message into a single line. Bolding whatever is on the first line would help in those cases, but I wouldn't try to make it specific to any particular character count; not everyone using Git is using an ancient text editor.

An easier step to this improvement can be https://jira.atlassian.com/browse/SRCTREE-4522?workflowName=SourceTree+Bug+Workflow&stepId=1

Indeed, an option to make the header text bold up until the 50th character would be nice. Vim does have that option.
The checkbox could be called Display commit message header text bold for the first ... characters

I was directed here by someone who kindly answered my Stack Overflow question about this topic. Obviously I voted on this issue because I'd love to see some minor attention for this.

Personally I do not prefer automatic line endings. Occasionaly you want to break the commit message guidelines. In fact, such automated assistance would not even solve this issue for me, because its downsides don't outweigh the extra help I get when writing that first line. Solutions to assist the commit guidelines would be much preferred IMHO. Suggestions that are better than automatic handling include:

• (An option to) make the first 50 (or X) characters of a commit message's first line bold.
• A second vertical guide at 50 characters, or possibly an "alternate" guide at 50 characters if the cursor is on the first line.
• Some row/col information on where the cursor is, much like many good text editors have. (This is the most flexible solution, because it would be useful for a wide range of other purposes too.)

Also, I do realize that extra visual clutter and/or even more settings come at a cost... counting on Atlassian to do what's best

The ability to add a second column guide would be trivial (I assume) and amazing. Automatic wrapping would be a great addition as well. Thanks Atlassian.

I've just voted for this; in particular Marcus's suggestion of bold for the first 50 characters and automatic wrapping at 72 characters would be greatly appreciated.

We don't even necessarily need 2 column markers at the same time. While you have your cursor on the first line it could be width1 (50). Once you hit return and you're on subsequent lines the column marker moves to width2 (72).

I'd definitely appreciate it!

Could you enhance the column guide so that you can enter multiple values? For example I would like to enter 50,72 to see 2 column guides then I can use 50 for the first line and 72 for all subsequent lines.

Also, I'd like to suggest that fixed-width font and column guides be enabled by default for new installs.

yawar.amin+atlassian This is actually the Mac JIRA project. The option isn't exposed in the Windows version options, I didn't spot that. The fixed-width font option will be exposed in the next version but the column marker isn't implemented yet.