Can you identify which plugin release was the last version you used which did not truncate?

I see the truncation, but rather assume it has been that way for a long time.

I think that truncation is not unreasonable, considering the recommendation for 50/72 formatting on stackoverflow, linux kernel recommendations, Chris Beams blog, Tim Pope's blog, and Caleb Thompson. I'm not aware of a change which intentionally truncated the commit message for display, but I see the truncation is happening.

Thanks for the comment Mark. As you can see from the screenshot the truncation has been introduced recently (sometime this year, took me a while to notice).

I have tried a few versions back to 2.2.6 but it still happens there. I will try and ask the Apache folks which versions they are running.

I'm not persuaded that it happened in the last year, since 2.2.6 was released Sep 2014 and you indicate that it is already there in 2.2.6. My initial suspicion is that the version which does not truncate is from the 1.x release series from a long time ago. However, I'm open to being proven wrong on that.

You could very well be correct, yes. Next chance I get I'll try to downgrade to a 1.x version.

I've tried 1.5 and you're correct: That does not truncate.

So I have a workaround for now but to me this still seems undesirable and like a bug. If you do agree - and I'm not sure about that - I'm happy to take a look at the code to see if I can find what's going on.

I prefer the current behavior of only showing a reasonable subset of the commit message in the UI presentation. My rationale is captured in my earlier comment on this bug. Other maintainers may have a different opinion, but for me, I prefer the truncation that was implemented in the 2.0 plugin rather than returning to the 1.0 unlimited length string behavior.

Thanks Mark. Shall I close the issue then?

(It seems as if 1.5 doesn't always work as it used to either, so I'll have to find alternatives to Jenkins anyway)

I think you should close the issue. If you're passionate about not truncating and willing to invest some effort in the plugin, you could consider creating a separate plugin (to add the behavior for those users who want it) or an optional extension of the current plugin which would modify the behavior to never truncate the change log message.

My QA department is beside themselves over the shortened comments.
They use these to document our changes, and this latest update has completely broken that.
We really want the comment to be as long as it is.
What is the value of truncating it? Could this at least be optional?

I would really like to discuss this with you. I'm not understanding the value to anyone of truncating the messages. We really want to see the entire thing.

I was looking for your earlier comment that was referenced above, and I can't find it. Would you settle for at least allowing a few hundred characters?

jlumpkins I'm sorry that your QA department is concerned about the shortened first line of the commit message in the message summary presentation. I believe it was done to keep the user interface from being mangled by long commit messages. It follows a pattern similar to the pattern used by GitHub (see this example) and gitweb (the web interface provided by the git project).

The community recommendations on git commit messages match with the behavior of the plugin. The recommendation is 50/72 formatting on stackoverflow, linux kernel recommendations, Chris Beams blog, Tim Pope's blog, and Caleb Thompson.

I am surprised your QA department was not also demanding the entire text of the commit message, since that is another form of truncation, and I believe that form of truncation was (I believe) already included in the earliest versions of the plugin.

I'm not willing to change so long-standing a behavior in the plugin without many more users complaining about it. I would expect many more complaints with it unlimited length than have ever been received due to the truncation.

If your QA department needs the full text of the commit message for a specific commit, why not configure the Jenkins job to use a repository browser for your organization, and point that repository browser to your git repository?

I would also like to see the full commit messages being output from the plugin. Let the length of the commit message be determined by the source system or team, not the consuming system. Other source control plugins (i.e.: TFS) provide the full commit/changeset message without any problems. While the community may recommend a specific length, plugins that consume the data shouldn't be the part of the process that enforces it.

It's been a while since I thought about this, but thanks for reminding me.

I agree with Ryan Milligan that the consumer of the data shouldn't truncate it arbitrarily.

Also, reviewing the comments on the site referenced: http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting I think you will find many other users that do not agree.

When you create an open source project that gains wide acceptance it seems like you have some responsibility to those that have come to depend on it to not make arbitrary changes that break reasonable work flows that rely on your project. The attitude that you wrote it, so if I don't like how you changed it, I should branch it and do it myself is not generally the spirit of the open source community.

If I can chime in, we use the Jira plugin to parse out Jira IDs from git commit messages to move the tickets through the workflow, and the truncated message has been an issue for us. For example, we'll have a git commit message, similar to

[AND-5186]: Fixes for Spanish Strings. Also: AND-5185, AND-5187, AND-5188, AND-5189, AND-5190

And in this particular case, it only processed 5185 and 5186 and not the others because of the truncation.

So yeah, if there's a way to preserve the entire commit message, would be a huge help.

thanks!

I'm quite surprised with the discussion and approach on this.
I'm maintaining the jira-plugin and as mentioned earlier, it depends on parsing the commit message.
The commit message is an integral part of a commit and should not be arbitrarily consumed by a plugin which role is to be an interface to git repository. References to github web UI or gitweb (again, web UI) are wrong as the purpose of those web UIs are different than a plugin that is a git provider.

warden I'm not sure how the Jira plugin requests the commit messages. It seems (from gkilleen's description) that the Jira plugin is reading the trimmed form of the commit messages as they are presented in the user interface, instead of using the git client plugin methods to collect the commit message from the git repository.

How does the Jira plugin request the commit messages?

The git client plugin (which provides API access to git repositories) provides various "changelog" methods which return changelog entries for ranges of commits. As far as I know, those API calls don't truncate. The truncation happens (as far as I recall) in the git plugin layer prior to presentation in the user interface.

The git plugin provides a user interface (recent changes list, links to source repositories, etc.) and workflow elements (submodule support, sparse checkout configuration, tagging, pushing commits back to the remote repository, etc.)

Mark,

Would this be a feature that would be difficult to make configurable? As you said its a recommendation, not a standard, and the recommendation is only a style preference. I'm sure there are many people out there who would like to be able to see the full change log at a glance even if it was a checkbox or update to a configuration.

I agree with Patrick. If this could be made configurable, with the default behavior being the current behavior, those of us that would prefer the full commit message could then toggle to option on the git plugin.

AFAIU the changes page at the project level only display the commit title (it is supposed to be its first line) while the changes page at the build level contains everything. And thus users would like to have all the logs in the changes page at the project level ?

aheritier the project level changes page displays the first line of the commit up to a certain number of characters. If the first line of the commit is longer than that certain number of characters, it is truncated in the project level view of the changes. The 1.x releases of the plugin would display the entire first line of the commit, no matter how many characters it contained.

Hi markewaite

Thanks a lot for your feedback. Thus it is a feature.
I had a look at the code and found the management of the commit title (first line)

• https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L229
• https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L462

Which isn't the case for others SCMs like the subversion plugin

• https://github.com/jenkinsci/subversion-plugin/blob/master/src/test/java/hudson/scm/SubversionChangeLogUtil.java#L8
• https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionChangeLogSet.java#L317

But I wasn't able to find where the line is truncated in the git plugin ..

Do you think that it may be an interesting improvement to allow configure the behavior (to not truncate the title line and to allow to display all the lines) ?

I would have no objection to a configurable behavior that would allow the full title line for those users who want things displayed the way git plugin 1.x did.

I too would like the entire first line of commit message to be included without truncation.

I am also observing an unexpected truncation of a commit message:

Original message:

'Please ignore this test build: feature/ECTSP-65-automate-fabric-build-distribution'

Truncated message:

'Please ignore this test build:'

This is behavior I do not get. Is there someplace where the commit message truncation behavior is specified?

farrukhnajmi if you read through all the comments on this bug report, you can find my assumptions of the rationale for the truncation. 

They are my assumptions only, not a mandate.  I believe the truncation change was made in the transition 3+ years ago from git plugin 1.x to git plugin 2.x.

If someone submits a pull request to add a git plugin option to not truncate the first line of the changelog message, and if they include automated tests in their pull request, I'm willing to evaluate the pull request.  I'm not willing to change the default behavior, so there needs to be an option.  I would accept that it could be a global switch that changes behavior for all jobs on that Jenkins server.

+1 for making this configurable.

+1 for making this configurable

markewaite This is one of the first issues I plan to tackle in the git-plugin. Since you are more familiar with the code base, do you know where (or roughly where) I would start to look for this truncating feature? 

Thank you in advance!

ckloehn thanks for your willingness to help with the code. That is great!

Refer to the changeset jelly snippet which generates the changelog. That jelly script uses the "it" variable to iterate over the GitChangeSetList.changeSets using the getLogs() method. That uses a ChangeLogSet to call the GitChangeSet.getMsg(). That uses GitChangeSet.parseCommit() to parse the commit and take the first line of the commit message as the summary.

I suspect the constructor for the GitChangeSet is receiving a list of strings which are wrapped (probably by format arguments passed to command line git) and the use of the first line of the commit message is what causes the truncation.

You might refer to GitChangeLogParserTest as a place to start your exploration with a debugger. Ultimately, I think you'll need to find the location in the code (probably in git client plugin) where arguments are passed to the command line git (and JGit) to format the list of changes for parsing by GitChangeLogParser.

I also created a regression test in my jenkins-bugs repository. I suspect that regression test needs more surrounding setup than you want to provide, but it is available if you need it. I use that regression test job in my Docker image to detect end to end behavior regressions.

markewaite Sorry if this is a bad question, but is there a way I can run the plugin locally with my own instance of jenkins to test things?

ckloehn that's a very good question. Refer to the jenkins.io plugin development section for an overview of plugin development. If you can't find what you need there, look at the older plugin tutorial and the debugging a plugin section for good pointers.

markewaite one last question about getting the project to build, I opened the pom.xml file with intellij and attempted a build. Unfortunately I could not find the package "hudson.plugins.git.Messages" so the project wouldn't build. I have done some searching for the file with little luck. Do you know where I might find it?

The file looking for the "Messages" package is AncestryBuildChooser 

The "Messages" classes are generated by maven at compile time. You might refer to Intellij for Jenkins or you might try compiling that project from the command line first (using Maven 3.5.0 or later - I use Maven 3.5.2).

a command line build is what I tried at first. however this also threw errors at me for some files it couldn't find. Specifically these two files were: 

git-plugin\target\classes\META-INF\annotations\hudson.Extension, and git-plugin\target\classes\META-INF\exposed.stapler-beans. 

I will take a look at the Intellij for Jenkins and see if that helps.

So I was able to get a successful build out of Intelllij, but it did not produce an .hpi file. My command line is still not wanting to build properly and because of that I am not finding a way to debug the plugin as suggested at the  debugging a plugin section. Thank you for all the help thus far markewaite

Here is the output I see from commands that I used:

private@stretch:~/tmp$ git clone https://github.com/jenkinsci/git-plugin
Cloning into 'git-plugin'...
remote: Counting objects: 25687, done.
remote: Total 25687 (delta 0), reused 0 (delta 0), pack-reused 25687
Receiving objects: 100% (25687/25687), 5.22 MiB | 8.65 MiB/s, done.
Resolving deltas: 100% (9883/9883), done.
private@stretch:~/tmp$ cd git-plugin/
private@stretch:~/tmp/git-plugin$ mvn --version
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.0-5-amd64", arch: "amd64", family: "unix"
private@stretch:~/tmp/git-plugin$ mvn clean install

At that point, a chunk of the internet is downloaded to my local cache.

I have a similar output 

C:\Users\kloehnc\Desktop\temp>git clone https://github.com/kloehnc/git-plugin.git
Cloning into 'git-plugin'...
remote: Counting objects: 25687, done.
remote: Total 25687 (delta 0), reused 0 (delta 0), pack-reused 25687
Receiving objects: 100% (25687/25687), 5.22 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (9883/9883), done.
C:\Users\kloehnc\Desktop\temp>cd git-plugin
C:\Users\kloehnc\Desktop\temp\git-plugin>mvn --version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T02:58:13-05:00)
Maven home: C:\Program Files\Apache\maven\apache-maven-3.5.2\bin\..
Java version: 9.0.4, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9.0.4
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
C:\Users\kloehnc\Desktop\temp\git-plugin>mvn clean install

However its the clean install that fails with no such file exceptions 

I will do that, as well as spin up a linux environment to try and match your set up. If all this fails though I don't have a way to run any manual tests, unless you know of any other ways to load my version of the plugin into Jenkins. 

So, after tracking this issue for a while, and getting excited over the last couple of days with Chris' involvement, I got a little concerned when the issue became Unassigned again and decided to dig into it myself.

It turns out that the issue is actually in git-client-plugin and not git-plugin at all.  It appears to be caused by this commit:

commit de49c9bf21f560ac3851c4f7ea3a3597a114ac8e
Author: Nicolas De Loof <nicolas.deloof@gmail.com>
Date:   Tue Feb 24 09:44:20 2015 +0100

    [FIXED JENKINS-27097] use ISO-8601 in changelog
    Use an explicit format string (to mimic raw format)
    to enforce ISO-8601 date format.
    Side benefit is this format string should not be
    impacted if a future/exotic git CLI do introduce
    some subtle changes in format=raw output.

Basically, an arbitary format was specified for the git whatchanged format:

commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b

The idea was good (to avoid changes in the format of the log pretty raw format), but it also introduced arbitrary wrapping early in the data processing which is probably not the correct place for it (altering the data during input).

Changing this to:
commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%s%n%n%b

fixes the issue.

I don't personally have the environment setup to test this fully, so if somebody can take this information and act upon it, I would be greatly appreciative.

If there is the desire to maintain the existing (arbitrary) wrapping behaviour, then I would suggest adding some sort of flag that allows disabling the arbitrary wrapping.  This should (hopefully) make everybody happy

andypoo please don't assign me issue without first discussing this with me. 

I indeed worked on this in the past but don't have bandwidth to look into this anymore

Nicolas: My sincerest apologies for that.  I assigned it to you given the previous commit and regression.

I'll continue looking into it directly myself.  It seems that my previous suggestion does not work when compiled into the plugin (still investigating why locally).

Thanks.

So, my mistake was not to account for the indentation that was added in addition to the wrapping.

This format works correctly:

commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(0,4,4)%s%n%n%b

Not released yet

What's happening with this issue? Is there a version of the plugin with this change?

randy_jones versions of the plugin with this change are available from the experimental update center. Current versions are git client plugin 3.0.0-beta7 and git plugin 4.0.0-beta7.

Several blocking compatibility problems were detected by earlier testing of pre-release versions of git client plugin 3.0 and git plugin 4.0. Released versions of those plugins won't be available until the blocking problems are resolved. Those blocking issues are described in the git client plugin 3.0 milestone and in the git plugin 4.0 milestone.

We'd love to have more users running the beta versions of those plugins.

Released with git client plugin 3.0.0 and git plugin 4.0.0 on Nov 2, 2019.