How to effectively review git submodule updates/rebases?

Question

Our project uses a git submodule to pin one of our library dependencies.

We regularly rebase the submodule to follow upstream changes, and we also have a set of commits on top of it that we cannot easily upstream.

When somebody rebases the submodule, I only see this in the git diff of the parent repo:

--- a/mysubmodule
+++ b/mysubmodule
@@ -1 +1 @@
-Subproject commit abc12345abc12345abc12345abcd12345abc1234
+Subproject commit efg67890efg67890efg67890efg67890efg67890

That is not very useful. When I git diff these commits in the submodule, I get a lot of output, including all of the upstream changes, with our commits on top buried in between. I cannot easily judge whether some of the conflict resolution performed on our own commits introduced some mistakes.

How can I effectively code-review the changes to the submodule?

Laden

Assuming you have evil collegues, the only good way to review any rebase is to redo the operation, make a temporary commit without resolving any conflicts; i.e. commit the conflict markers, and then compare that commit to the one made by your collegue, which will show exactly the changes corresponding to how these have been resolved. The same thing applies to merges; only by redoing it can I see immediately what other changes they have snuck in. – Franke

Answer 1

Use git range-diff. It was designed for exactly this purpose, to review commit ranges.

If your parent commit repo has:

-Subproject commit abc123
+Subproject commit efg678

then cd into your submodule and run (note triple-dots ...):

git range-diff abc123...efg678

---

Example output explained:

• Each commit line shows the commit SHA before and after the rebase.
• The green lines at the top show new commits in the upstream project. Read them if you want to want to see what changed upstream since you last rebased.
• Yellow lines show commits unchanged by the rebase.
• Red lines are commits that were removed as part of your conflict resolution (e.g. if you contributed one of your patches-on-top into the upstream project).
• Green lines are commits that were added as part of your conflict resolution (e.g. if a new customisation was necessary to make your project work with the new upstream code).

• Red-and-green lines show commits that were changed as part of the rebase (e.g. when a conflict resolution had to change your commit-on-top in order to work with modified upstream code).

  When they appear, they also include a normal diff so you can inspect the difference.

As part of your review, you should especially check whether addition/removal of your commits-on-top look right (or if some were accidentally dropped), and whether the conflict resolution (red-and-green lines) looks correct.

Laden