Skip to content

Conversation

Punpun1643
Copy link
Owner

Fixes #xxxx

Proposed commit message

Brief description of current behaviour and reason(s) for the change.

Call-to-action statement describing what you are doing in this PR.

Other information

Punpun1643 and others added 13 commits June 6, 2022 22:39
…ense#1776)

The use of Instant.ofEpochMilli(Long.MIN_VALUE) as the arbitrary first
commit date now fails shallow cloning for
testSinceBeginningDateRangeWithShallowCloning system test.

In addition, using this arbitrary date in convertToGitDateRangeArgs
when converting timezone results in an overflow causing sinceDate to
be greater than untilDate. Thus, no commit results are retrieved,
leading to failing system tests.

Also, the arbitrary first commit date is in UTC. However, in the
convertToGitDateRangeArgs method, the zoneId used for the conversion
is from the config, which may be different. This leads to an erroneous
timezone conversion.

Finally, using --since d1 with --period results in an unintended date
range because the --period and the arbitrary commit date from 
--since d1 are used to calculate the until date as the actual 
earliest commit date is not immediately available.

Let's change Instant.ofEpochMilli() to use 0 so that the arbitrary date
is 1970-01-01 and the overflow of the sinceDate can be avoided.

At the same time, let's convert the arbitrary date to the correct
timezone within the ArgsParser class and add a component test for
parsing --since d1 to check that the correct timezone is used for each
RepoConfiguration before cloning any repos.

Finally, let's raise a warning when --since d1 is being used with 
--period.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants