Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Incomplete
-
Mercurial plugin 1.54
jenkins 1.624
Mercurial 3.5 (seems to happen on older versions as well)
Description
the hg change log that is generated from:
hg log --rev branch_name:0 --follow --prune hash_name
includes every commit in a repository for me, I've tested this on 3-4 repos with a few different version of hg.
it seems to produce the right info with:
hg log --rev branch_name --follow --prune hash_name
not sure if a problem is that branch name = diguy-13_0-ecosim (but "diguy-13_0-ecosim:0" doesn't behave any differently
Attachments
Issue Links
- duplicates
-
-
- Resolved
-
Activity
we are using the multiple scms plugin. Which seems to produce less then ideal change info (hash keys are listed but not clearly associated with a repo in the UI). I'm wondering where the :0 argument is coming from since removing that on the command line seems to do the right thing.
Gedalia Pasternak
added a comment - - edited we are using the multiple scms plugin. Which seems to produce less then ideal change info (hash keys are listed but not clearly associated with a repo in the UI). I'm wondering where the :0 argument is coming from since removing that on the command line seems to do the right thing. Gedalia Pasternak
added a comment - there's a good chance it's the same as https://issues.jenkins-ci.org/browse/JENKINS-28526 since we're using 3.4+ and it spontaneously started when we upgraded versions
Gedalia Pasternak
added a comment - there's a good chance it's the same as https://issues.jenkins-ci.org/browse/JENKINS-28526 since we're using 3.4+ and it spontaneously started when we upgraded versions 
Cannot diagnose without a way to reproduce from scratch. The --prune option is supposed to be truncating the log at the revision checked out by the previous build, leaving you with the commits in this build.
If you are using the Multiple SCMs plugin, that is possibly involved.