Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] RevCommit.getShortMessage() length
On Thu, Jul 26, 2018 at 5:14 PM Mark Waite <mark.earl.waite@xxxxxxxxx> wrote:


On Thu, Jul 26, 2018 at 7:16 AM Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
On Jul 26, 2018, at 14:38, Mark Waite <mark.earl.waite@xxxxxxxxx> wrote:

On Thu, Jul 26, 2018 at 4:44 AM Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
Would it make sense to limit the length of the string returned by RevCommit.getShortMessage()?
(And RevTag.getShortMessage().)


I think it might be a mistake to truncate the message so close to the git repository API.

It is not about the commit message as a whole, it is about the summary line.

In the Jenkins project 3 years ago, the API code that is called to present log messages to users was configured to truncate a summary message in the Jenkins user interface.

https://issues.jenkins-ci.org/browse/JENKINS-29977 shows the history of several different users having problems with that change at the user interface level.  I would expect even more complaints from consumers of an API like JGit.

On the other side of the argument, the name of the method is "getShortMessage" (emphasis on the word "short").  The name seems to me like it justifies returning something less than the full message.

That is the point. And I thought that my proposition of 500 characters was so
far beyond any recommendations for the length of that summary line that
truncation would in practice rarely occur.

Even in the discussion on JENKINS-29977 nor in the discussion linked in there
on stackoverflow nobody presented an argument for why a summary line of a
commit message should ever be that long. There's even some data presented:
(The rest of the stackoverflow discussion was more about line wrapping the
rest of a commit message.)

Does a summary line of 500 or more characters make sense? Or more?
The examples given in JENKINS-29977 are well below that.


I don't think a summary line more than 500 characters makes sense.  Unfortunately, interactions with end users have often persuaded me that things which don't make sense to me often make sense to others in some case which I had not considered (as in JENKINS-29977).

I'm fine if the message is truncated by the JGit API as you have proposed.  JGit will be different than command line git in that case but the difference is unlikely to be detected in the cases where Jenkins uses the JGit API.

The JavaDoc of this method says:

Parse the commit message and return the first "line" of it.

The first line is everything up to the first pair of LFs. This is the
"oneline" format, suitable for output in a single line display.

We would break the definition that the first line is everything up to the first pair of LFs when truncating the result.
Though a pathological first line of 90MB would be not suitable for output in a single line display.

I think instead of truncating when reading the commit message the better cure for such problems would be
to validate the length when the commit is created or pushed to a shared repository.
This can be achieved e.g. using hooks or e.g. the Gerrit commit-message-lenght-validator plugin [2].


-Matthias

Back to the top