[JENKINS-51633] Calculate Changelog against a specific branch should allow empty remote

My use case involves doing revision comparisons between two tags (each representing a successful build) for projects based on GH.

Via command-line, the way I could get the right behavior was (where test-1.0.1 and test-1.0.0 are tags created by a separate process unrelated to my particular jenkins job)

$git whatchanged --no-abbrev -M test-1.0.1 ^test-1.0.0

Using the plugin with the remote branch required only allows something like:

$ git whatchanged --no-abbrev -M test-1.0.1 ^origin/test-1.0.0

fatal: bad revision '^origin/test-1.0.0'

Perhaps there is some other trick that would allow me to gain the same effect, but I don't see the downside of this improvement in any event.

Note that the current documentation for the behavior is:

Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

 

So, since the plugin already requires a workspace and cannot compute the changesets solely on the remote side, I see no advantage of requiring a remote name.

---
Originally reported by aegarland, imported from: Calculate Changelog against a specific branch should allow empty remote

• status: Open
  
• priority: Minor
  
• component(s): git-plugin
  
• resolution: Unresolved
  
• votes: 2
  
• watchers: 5
  
• imported: 2025-12-02
  

Raw content of original issue

My use case involves doing revision comparisons between two tags (each representing a successful build) for projects based on GH.


Via command-line, the way I could get the right behavior was (where test-1.0.1 and test-1.0.0 are tags created by a separate process unrelated to my particular jenkins job)



$git whatchanged --no-abbrev -M test-1.0.1 ^test-1.0.0



Using the plugin with the remote branch required only allows something like:



$ git whatchanged --no-abbrev -M test-1.0.1 ^origin/test-1.0.0

fatal: bad revision '^origin/test-1.0.0'



Perhaps there is some other trick that would allow me to gain the same effect, but I don't see the downside of this improvement in any event.


Note that the current documentation for the behavior is:

Using this behaviour will preclude the faster git ls-remote polling mechanism, forcing polling to require a workspace thus sometimes triggering unwanted builds, as if you had selected the Force polling using workspace extension as well.

 

So, since the plugin already requires a workspace and cannot compute the changesets solely on the remote side, I see no advantage of requiring a remote name.

• environment: jenkins 2.107.3 git-plugin 3.9.0

1 attachment

- [image-2018-06-01-13-04-14-599.png](https://issues.jenkins.io/secure/attachment/42763/image-2018-06-01-13-04-14-599.png)
>