Support the popular Git commit message format

[lessawe]

First of all, thanks for the software! I tried it yesterday and it looks promising. With some adjustments in the upcoming few weeks, it could really become a product worth buying!

I’d like to create a message here in the forum because I could not find any bug/feature tracker for Sublime Merge.

I’d like to suggest that Sublime Merge should (optionally) support the popular Git commit message format. That means that the subject line should be 50 chars long and the body part of the commit message 72 chars. If the body part is provided in the commit message, there should be a blank line in between.

IntelliJ supports this feature and it’s really a good thing. So, in IntelliJ the line is hard-wrapped for 72 chars and displays a warning for the subject line if it’s beyond 50 chars, see the screenshot:

It would be very cool if Sublime Merge could support this. Thanks in advance!

[OdatNurd]

In many ways we’re most of the way there already. For example, I’ve been running the following as my commit message settings:

{
    "syntax": "Packages/Git Formats/Git Commit.sublime-syntax",
    "rulers": [50, 72]
}

That sets up appropriate rulers to help guide commits. There’s no hard wrapping at the moment (either automatically or manually since the wrap_lines command is not available yet), but the guides help in the interim.

Perhaps the interesting bit is that this uses the syntax from Sublime for git commit messages, which gives more visual impact to the commit messages, like making the first line bold and other syntax hints that are useful:

As such it’s possible to have a syntax in place that would highlight the parts of the first line that are greater than 50 characters as invalid to visually remind you, although I imagine the problem with that is that there are likely varying opinions on the width of commit message bits.

Presumably when we get plugin support that could be fixed by having the plugin use a setting to add a region around the extraneous text or some such.

[deathaxe]

… Damn, was too slow.

[OdatNurd]

While I was typing that I had the sense I was racing a clock of some sort…

[lessawe]

Thanks for your reply, @OdatNurd!

It would be a good thing to have that integrated into Sublime Merge out of the box. Of course, it does not have to be activated by default, but it should be there to set it up easily.

Hard wrapping and warning for the subject line is missing (… and proper documentation for the settings).

[14b56]

I’d like to have such a feature as well, make correct formatting easier

[mlf]

With a slight modification of the “Git Commit.sublime-syntax”, you can get the color effect too:

This gives something like that (assuming the default theme):

[lessawe]

Very cool, @mlf. So it should be relatively easy for the sublime devs to include that feature into Sublime Merge out of the box and also add hard-wrapping.

[kingkeith]

but some of us don’t like these ridiculous for-terminal rules… I hate hard wrapping, looks silly everywhere else and less readable

[lessawe]

Yeah, that’s why it should be optional. However, at many places the 50/72 rule is used.

[deathaxe]

Using look-behinds is no option as they are not supported by sregex and therefore trigger old Oniguruma.

[mlf]

I’m not sure the possible performance impact would be relevant, though, for git commit messages.Do I miss something?

[deathaxe]

Just to make sure the syntax doesn’t get broken if the old Oniguruma might be dropped some day all new or refactored syntaxes must IMHO pass the Syntax Tests - Regex Compatibility checks.

[mlf]

Without look-ahead/behind, it’s not really possible to properly highlight column-delimited formats (say, mainframe stuff, like Cobol or even C on said systems). If it were to be removed, it would significantly reduce the usefulness of it (at least for me ).

[Actually, regular expressions are not expressive enough, even with look-ahead/behind, but it’s close.]

But this is out of scope for this current thread, so I will shut up

[deathaxe]

The line length limitation is not part of the syntax.

There is nothing wrong with longer message lines. They aren’t forbidden per syntax definition or rejected by git. Therefore highlighting them as invalid illegal is just wrong.

What we talk about here is linting. Some projects/people might have chosen the [50,72] limit as style guide for their commit messages and violations should be highlighted. Same way as some python projects prefer 80 characters per line and others do 100 or 120. None of the limits exists in the syntax though! It’s just a choice of personal taste.

Adding such a rule to Git Commit.sublime-syntax would bother everybody with that limitation if that syntax was applied to the Commit Message.sublime-syntax by default.

This argues to just not add such limitations by default. Everybody is free to extend the Git Commit.sublime-syntax to highlight lines as illegal and assign it in user settings.

[lessawe]

@jps: What’s your opinion about this issue?

[matthiasr]

@mlf I would be really happy if you could show the complete Git Commit.sublime-syntax file?

[mlf]

The highlighted lines in my post above are the only change in the syntax file (as of build 1104 at least, i.e., the current dev one).
You can simply extract it from the “Git Formats.sublime-package” package (its location dépends on your OS and install choice), which is a plain zip file.
Change this extracted file, and put it in your “Packages/User” directory so that it takes predominance.

[matthiasr]

Finally got it working - thank you!

[tomasland6]

Hi there. Everything works great. Thanks.