Another +1 for this. We've only run into this once so far, but it created major disruptions and false alarms between numerous teams.

It sounds like this limit was originally put in place to prevent OOM issues; if that's still the case, making this a configurable option might be a good solution, at least for self-hosted instances.

Then perhaps have a fallback to the original value on next boot if OOM was encountered as a safety measure.

+1 on this issue. I don't understand why this is a feature request. Changes aren't tracked in the build logs and apis. Any way you cut it, this looks like a bug.

+1 on this issue if possible please! While it's always desirable to deploy little and often, circumstances mean that it's not always possible to do this. 

 
Please fix it quickly!!!

My site show me "Showing 100 of 336 code changes", we need to check the history of all 336 code changed.

@yprakesh I wrote a small script to parse ticket numbers from the commits to bypass this limitiation as alternative.
You will find it on github:  https://github.com/echorebel/generate-changelog

This also creates versions and sets fix version in the ticket and compiling it all down to a changelog file too. You can take it and/or modify to your needs of course.

Quite disappointing & annoying given that REST also doesn't provide any related data.  This is such an important feature but getting ignored for almost 7 years. @Bamboo team has any plans on this? Also anyone found any alternatives?

Just discovered after searching why commits not deployed according to jira. Should ba a configurable parameter.

Just adding a comment to express my desire that this limitation be addressed

Please change this limitation to configurable setting.

Add the max number to a config file, or provide at least some way to override it when writing plugins. For Svn repos, this is impossible without a custom implementation of AbstractSvnExecutor, At least for Git repos it gets that number from a config file (but have not tried if that works). 

My use case is that I need to collect all commits linked to a Jira release (i.e. certain Jira issues). With a lot of commit activity, we quickly have 100 commits in a matter of days. And sometimes we want to use this for older releases. Definitely need to go back more than 100 commits, in my case, I need to go back to the first commit to make sure I scanned all comments.

Couldn't believe my eyes and took me some time to find this issue.

We do git flow and production releases from master too like @jamie. We run with two (and growing) teams on one code base.

I agree there should be not so many changes per release but Bamboo should not just have a hard cap on changes and just hide the changes from everyone. Think about generated changelogs and automatically fix versions set in the Jira tickets.

I would suggest moving this to a bug too!