Get stash to stop truncating the git commit message

[Paul Wisner]

Description : The descriptions of pull requests are based on the git commit message.

These descriptions are critical to describe why a change is being made, how the change works and how the change has been tested by the developer.

Unfortunately stash is truncating the descriptions to 584 characters or maybe 11 lines.

Is there a way to get stash to accept and show a commit message of any length?

We are using stash V2.12.3.    Would upgrading help?

[Stefan Saasen]

Unfortunately upgrading won't help at this stage. We have an open issue regarding this: https://jira.atlassian.com/browse/STASH-5198

I've added a link to your questions to the issue.

[Bryan Turner]

I'll add that Stash applies a hard 32768 character limit at the database level, so there will always be some level of truncation enforced here. That said, I'm all for removing the early truncation the UI currently does; given the database has room for a lot more characters than the UI is using, it'd be nice to use them.

[Mike Friedrich]

Thanks for the explanation. Stash seems to behave differently if you have more than one commit in a pull-reuqest (often the case for us); and it looks like our developers seldom write longer descriptions.

[Paul Wisner]

@Mike Friedrich

The headline is short and is followed by an empty line.   The description is getting truncated.

To be absolutely clear, I made this example based on the "model git commit message" from http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

For example, when I make a PR based on a change with the following commit message:

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug."  This convention matches up with commit messages generated
by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent

When I view the branch in stash the full message is visible and there are no changes to the formatting.

However, when I make a pull request the message is truncated to:

Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug...

The ellipses were added by stash.  Another problem is that some newlines were removed - defeating efforts to make a readable message.

[Mike Friedrich]

How is it truncating? I have seen it only putting each commits headline in the PR details - and was happy with it.

Git recommends restricting the headline length as several tools truncate these messages or have problems displaying it. Ar you guys saying (some) your headlines are, say > 120 charcaters long? Or are talking about the commits message detail sections?

For us, some developers forget the blank line between headline and details of the commit message, for these cases i require Stash to truncate that for me. (Stash 3.2)

[Paul Wisner]

The intended audience of the full commit message is the code reviewer. That's why it's so important to have the full message with the PR.