merge commits do not have timestamp information. They get "checked" easily without doing any external requests - they are effectively "skipped".
merge commits have 2 parent commits - the first points to the previous commit in the main branch (often that is another merge commit from an older PR). The second parent points to the real commit(s) chain from the PR that was merged. Those commits do have timestamp information to check.
So it would be useless to just follow the first parent commit each time back through the main branch, that will miss most of the real commits with timestamps. And following the second parent commit will not really be faster than following both parent commits, because the merge commits are "checked" quickly anyway.
So IMO the way to reduce time is to provide a way to limit how far back we check.
MAX_COMMITS_TO_CHECK defaults to 0 and in that case we treat 0 as infinity and check back through all commits to the root commit of the repo.
Set env var MAX_COMMITS_TO_CHECK to some positive integer to limit the number of commits to check.
We might want to check 10 or 20 in the CI of a PR?
Signed-off-by: Phil Davis <phil@jankaritech.com>
Fixes #8
- merge commits do not have timestamp information. They get "checked" easily without doing any external requests - they are effectively "skipped".
- merge commits have 2 parent commits - the first points to the previous commit in the main branch (often that is another merge commit from an older PR). The second parent points to the real commit(s) chain from the PR that was merged. Those commits do have timestamp information to check.
So it would be useless to just follow the first parent commit each time back through the main branch, that will miss most of the real commits with timestamps. And following the second parent commit will not really be faster than following both parent commits, because the merge commits are "checked" quickly anyway.
So IMO the way to reduce time is to provide a way to limit how far back we check.
`MAX_COMMITS_TO_CHECK` defaults to `0` and in that case we treat `0` as infinity and check back through all commits to the root commit of the repo.
Set env var `MAX_COMMITS_TO_CHECK` to some positive integer to limit the number of commits to check.
We might want to check 10 or 20 in the CI of a PR?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Signed-off-by: Phil Davis phil@jankaritech.com
Fixes #8
So it would be useless to just follow the first parent commit each time back through the main branch, that will miss most of the real commits with timestamps. And following the second parent commit will not really be faster than following both parent commits, because the merge commits are "checked" quickly anyway.
So IMO the way to reduce time is to provide a way to limit how far back we check.
MAX_COMMITS_TO_CHECKdefaults to0and in that case we treat0as infinity and check back through all commits to the root commit of the repo.Set env var
MAX_COMMITS_TO_CHECKto some positive integer to limit the number of commits to check.We might want to check 10 or 20 in the CI of a PR?
@@ -42,6 +42,7 @@ if [[ ! -d "$DIR" ]]; then DIR="$PWD"; fi. "$DIR/timestamping"declare -i MINVERSION=$TIMESTAMPING_VERSIONdeclare -i MAX_COMMITS_TO_CHECK=20what about setting it to infinity for default, so that the original behavior does not change
Done
0means "infinity" and is now the default.