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 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.

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.

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?
 
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?

Mark Waite
 
For a command-line client it's not really a problem, but for an IDE it may be. At least it
may lead to crazy layouts in the UI and consume more memory than intended, or some UI
components may get into real troubles when they're asked to display extremely long lines.

Yes, clipping the short message length could be done in the UI, but it would have to be done
in several places, which is error-prone. And the reflog at least would still end up with these
long messages. So I think if it's done it should be done in {RevCommit,RevTag}.getShortMessage()
directly.

How about a limit of 500 characters?

(It's not purely hypothetical. There recently was someone who had a commit message with 90M
characters. In the first version of the unit test I wrote for this, I promptly forgot to give
the test commit a proper short first paragraph. I don't like it if tools can break easily when
users do unexpected things.)

--
Thomas
_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jgit-dev

Back to the top