search

UWB-Biocomputing / WorkBench

Software and data provenance management platform for simulations of dissociated cortical cultures.
https://uwb-biocomputing.github.io/WorkBench/
Apache License 2.0
1 stars 3 forks source link

Add ability to compare commits #65

Open stiber opened 3 years ago

stiber commented 3 years ago

Dragging one commit or another could allow us to grab the two commit IDs, use the GitHub API to provide the diffs between the two commits, and then display those diffs somehow (embed a web view?).

Kingmandeep commented 3 years ago

If I create a merge request then push another commit to it after creation, lets diff between the two sets of commits from the Changes tab. This is very useful to see only what has changed in the most recent set of commits. This feature would be even more useful if it were extended to compare between any two set of commits in the merge request. Often, commits are separated logically, and without this feature it becomes very difficult to review certain types of changes.

Example Here's an example:

(base commit) Commit 1: Moves 500 source files, with no functional change Commit 2: Moves 250 more source files, with no functional changes Commit 3: Change some project/make files (18 files) Commit 4: Oops, I forgot some of the make files (3 files) Commit 5: Oops, I used tabs instead of spaces (4 files)

In this case, it is very tedious to view the compare as a whole, because the real changes made by a human that should be more heavily scrutinized (commits 3-5) are lost among all of the file moves. This could be mitigated easily by giving users the option to compare between commit 2 and commit 5 in the merge request, and allow them to make comments on the review. (A user may also want to just view and comment on a diff of Commit 2 vs. the base commit.)

stiber commented 3 years ago

Good point, @Kingmandeep. There is a simple case, where there is a very specific change to a very small number of files. And then there are commits with many changes, few of which are substantive.

I think the general case isn't solvable, or else GitHub would have already done it. However, we have an advantage that we don't need to solve the general problem. We have a lot of knowledge about our simulator and might, in principle, be able to distinguish between substantive and non-substantive changes, or at least filter out classes of changes that are clearly not informative. This sounds like a good project for a student to explore!