Merge #19654: lint: Don't use TRAVIS_COMMIT_RANGE in commit message linter

72351784b3df21a89f79076f4b814a6e700b6469 lint: Remove travis env var from commit linter (Fabian Jahr)

Pull request description:

  #19439 was recently merged and seemed to work fine but I now noticed strange behavior when it was running in Travis, which I could not reproduce locally. It turns out `TRAVIS_COMMIT_RANGE` which is used in Travis to get the commits for the linter, uses all the commits that were in a push, which includes all rebase commits for example. This means that the linter can fail on a commit that the developer has never even seen before, which can be very confusing. See an example here which caused me to look into this: https://travis-ci.org/github/bitcoin/bitcoin/jobs/714296381 The commit that is reported as failing in my PR is not part of my PR.

  I think we rather want to use something like `git merge-base` to get the commit range by default and in Travis. I am leaving the env variable functionality in place with a different name but this is not a variable that can be expected to be present in the CI environments so the `merge-base` range should be used there by default.

ACKs for top commit:
  hebasto:
    ACK 72351784b3df21a89f79076f4b814a6e700b6469, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: afb27bb386855cb8d5cf84fd3a6c11ef1160b25af6175ed0aa146bf04b9a26eb77298df70df0a855f8c46f19f08b3f62c49872c12974fcfa5526a15ee05b3c10

0 files changed, 0 insertions, 0 deletions