use git log that acts like git whatchanged. include merge commits

[burnettk]

we ran some tests that compared the output of git log and git whatchanged on several repos, and determined that this set of arguments made them act the same for our repos. then we removed the --no-merges flag from git log so it will include merge commits per https://issues.jenkins-ci.org/browse/JENKINS-28907 (see also the comment there). updated all references to git whatchanged in comments, since whatchanged no longer appears in the source code of this repo.

working w/ jasquat.

[burnettk]

i'll pull the classic "the master build failed with the same test failure at around the same time that it failed for my branch" defense (for the continuous-integration/jenkins/pr-merge check). sorry about that.

[MarkEWaite]

Yes, that test failure is happening only on Windows, and has resisted my attempts to fix it. It passes on my Windows machines, and passes on my Linux machines. I'll investigate further today or tomorrow.

[burnettk]

well i actually tried installing the hpi generated from a maven build off this branch and it didn't seem to do what i would have expected. the following changes in the screenshot include merge commits, but it's still only showing the one non-merge commit instead of both the normal commit and the merge commit. i also tried changing the line in question to totally botch it ("git borked" instead of "git log" or "git whatchanged") to see if that would break everything, but it didn't break jenkins like i expected it to. maybe that line isn't used, or maybe my testing process was bad (i maven built, grabbed the hpi, shoved it up via the upload plugin UI, and then restarted jenkins).

[andrew-garland]

@burnettk For me, the addition of --diff-filter=ACDMRTUXB prevents including merge commits.

Since the only differences cited between git log and git whatchanged are the default format and excluding merges, I would guess that you don't need it. https://git-scm.com/docs/git-whatchanged

[burnettk]

i was intending to keep the functionality as close to the existing functionality as possible while adding merge commits. are you suggesting removing the --diff-filter argument entirely? i also suspect @MarkEWaite won't merge this even if it's working as intended, since we talked at jenkins world one time, and the concern is that people are depending on the existing no-merge-commit functionality, right or wrong. :) this is still a major bummer for us--and i suspect you--so any thoughts about a way forward are welcome.

[andrew-garland]

@burnettk I didn't spend as much time researching as you did, but for my GH project, it seemed that adding the --diff-filter also eliminated all merge commits. I know that wasn't your intention (you specifically stated that you wanted a filter that excluded nothing), so maybe there is something else going on in my setup.

On the other topic, one way to make it backward compatible is to add an additional option to the configuration screen.

By default, the values would be exactly as it is now, e.g.:

Global changelog generation base command: whatchanged --no-abbrev -M

In my case, I would change it to:

Global changelog generation base command: log --raw --no-abbrev -M

If it was too much work to change various interface definitions to pass in this string, then a less elegant approach would pull the values from a system environment variable (an approach that is already implemented in that class for other constants):

public static final boolean GIT_CHANGELOG_COMMAND= System.getProperty(CliGitAPIImpl.class.getName() + ".changelogCommand", "whatchanged --no-abbrev -M");

If someone needed different formats for different jobs, then it would have to move into the additional behaviors for Git, which seems unlikely to be worth the effort IMO.

[burnettk]

either of those options you mentioned to support configuring this command would be awesome from my perspective.

[andrew-garland]

@burnettk BTW, I did the same testing as you (maven build, upload hpi) and after removing the diff-filter, I now see merge commits too. You might want to retest yourself. Do the extra commits you see due to "rev.always_show_header = 1" impact you, or were you just trying to maintain backward compatibility?