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.
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.
It is quite simple to get longer-than-intended summaries; just forget the empty line between the summary and the rest of the commit message text.
Would it be helpful to add an integer argument to the API which is the upper bound on the number of characters in the returned string? Would that be enough to both address your concern and still support the use cases as reported in that Jenkins bug report?
No, then I would rather do it in the IDE. The reflog would still have nonsensically long summary lines, and I'd clip them after reading. Of course, reading long summary lines already is slower... What if someone has a commit message with a first paragraph that is really long? We'd end up
with such really long messages in the history and the reflog and I don't know where else.
I assume that a long first paragraph will be written into the history and the reflog by command line git. If the natural mode of JGit is to truncate, won't that result in complaints from JGit consumers that this is a case where it is not matching the standard implementation of command line git?
Maybe. I don't know. Maybe standard git should also truncate summaries?
Again, note that I'm not talking about truncating summaries at 72 or 80 characters. I'm more concerned about summaries with unintentionally ridiculous lengths. Truncating at 500, or if you prefer 1000 characters, should work to satisfy current use cases and avoid problems if a summary line is really much longer. I'm sure Jenkins users wouldn't be happy to be served a 90MB summary line on the web UI...
-- Thomas
| 