[#1877] Show merge commits in the report

[ckcherry23]

Fixes #1877

Proposed commit message

Currently, merge commits are completely ignored during report generation
and analysis. This misrepresents the number of commits the user has made
and misses out on important information included in the merge commits,
such as tags.

Let's include merge commits in the report so that important information
in such commits is not missed out.

Implementation details

• To include merge commits in the reports generated by the backend, I have modified the git log --no-merges to be git log --full-history.
• The git log command now also returns the parent hashes of the commit, and I determine whether it is an isMergeCommit based on whether it has more than 1 parent hash.
• The Ramp Chart shows merge commits now as very thin ramps.
• The Commits Panel shows all commits including merge commits when all file types are selected. When only some file types are selected, empty merge commits are not shown (since they do not come under any file category). We could extend this to explicitly show/hide merge commits from the commits panel.

Other changes made:

• Backend unit tests: Created test branch 1882-CommitInfoAnalyzerTest-analyzeCommits_mergeCommits_success in testrepo-Alpha
• Backend system tests: Regenerated all commits.json files
• Frontend cypress tests: Made 2 commits with Eugene's credentials in the cypress test branch

[damithc]

@ckcherry23 thanks for taking this up. When ready, also post a screenshot.

[yhtMinceraft1010X]

• The Ramp Chart shows merge commits now as very thin ramps. Ramp sizes are now calculated based on insertions + deletions instead of just insertions.
• File changes are now shown as +60 -12 lines instead of 60 lines.

With regards to these points, I'm of the opinion that changes to the ramp size calculation and file changes display should be done in a separate PR (which I think can solve #1042), and once that is merged, continue working on this PR.

What does everyone else @reposense/active-reviewers @reposense/devs think?

[ckcherry23]

@ckcherry23 thanks for taking this up. When ready, also post a screenshot.

Here's a screenshot of the behavior now. Will update again based on my peer reviews.

This is the repo that was used to report the bug. The light blue ramps are for 2023-01-29, and have 3 merge commit ramps between 2 normal ramps. The Commits Panel has the merge commits and the previously missing tags as well.

With regards to these points, I'm of the opinion that changes to the ramp size calculation and file changes display should be done in a separate PR (which I think can solve #1042), and once that is merged, continue working on this PR.

Okay, I think I will make the changes to ramp size calculation and file changes separately to limit the scope of this PR.

[damithc]

With regards to these points, I'm of the opinion that changes to the ramp size calculation and file changes display should be done in a separate PR (which I think can solve #1042), and once that is merged, continue working on this PR.

Yes, this requires more deliberations.

[chan-j-d]

The backend changes look pretty good. I think it might be necessary to add some new unit tests to check if merge commits are correctly identified

[HCY123902]

The current changes look great to me. You can request a separate review from me as soon as you complete the cypress changes.

I only have 1 more doubt. This is again related to the case where a merge commit contains changes for conflict resolution.

According to this post and this post, git log --numstat does not actually diff a merge commit against either of its parent by default, because it does not know which parent to compare with. To actually get the number of additions and deletions, there has to be an additional option such as -c, --cc, or -m to either combine or pick the difference.

According to the posts, -c and --cc will only compute differences for a merge commit that is different from both of its parents, meaning that the merge commit contains additional changes for conflict resolution, and other merge commits will again be skipped. The -m option compares the commit with each of its parents separately.

I am not sure about the current behavior of the wrapper class in GitLog.java. I do not think what I mentioned above is significant either at the moment, because it may introduce additional complications to the logic. Instead, this can be handled in the future in a separate pull request

[HCY123902]

It seems that there are 2 cypress cases regarding zoom view that did not pass. Can you take a look

[zhoukerrr]

I am only reviewing the frontend side of this PR. LGTM! The cypress tests looks good to me as well.

[chan-j-d]

LGTM! Unit tests look good and the frontend changes seem to work well. Great work!

[github-actions]

The following links are for previewing this pull request:

• Dashboard Preview: https://dashboard-1882-pr-reposense-reposense.surge.sh
• Docs Preview: https://docs-1882-pr-reposense-reposense.surge.sh