commit 9c38d22cc23836605a8ffb1d3abc34b9e2d9fe57
author Alice Kober-Sotzek <aliceks@google.com> Tue Sep 08 17:43:01 2020 +0200
committer Alice Kober-Sotzek <aliceks@google.com> Wed Sep 09 15:15:40 2020 +0200
tree 2f1eecde6073e5a3cb0ba2f91b657e370f8f48b3
parent 778c868ce7d76e1ad6c2e8ecbb8afa2cac78b508

Also port comments added on base/parent(s) (= "left-side" comments)

Previously, we filtered such comments as we didn't have the proper
porting logic for them in place. That logic requires that we use the
commit on which the comment was actually added and the commit to which
it should be ported. For comments directly added on a patchset commit
(= "right-side" comments), we could simply use the commits of the
original and target patchset. For comments on parent/base commits, we
need to lookup those commits first, which might even mean the generation
of the auto-merge commit on the target patchset if a comment is on
an auto-merge commit. Of course, we only lookup the commits we really
need for the porting computation.

For merge commits, we decided to support any possibly referenced parent
commit (e.g. auto-merge, parent 1, parent 2, potentially parent X if
the SHA-1-lookup mechanism supports parent X). Thus, the ported
comments feature stays independent of any restrictions we put on
comments (which might easily change over the lifetime of Gerrit).
Considering that we have restrictions in place but don't enforce them
on all endpoints (e.g. published comments may only be added on
auto-merge and not parent 1/2 for merge commits but draft comments may
appear anywhere and can be published afterwards) and that old comments
would never follow newly added restrictions, that's probably the safest
choice. Having that flexibility didn't cost us anything (as we needed
to cover each possible scenario in tests anyway).

Change-Id: I1a41bffe1bdcba412ce5c1d3c40f80894c3bfa60