tree 88fcc0a62d4dcf9f0378de1678a011f4ac844d89
parent 5a5dbfdf3b224351c33cefa313aa2239aaab90fb
author Alice Kober-Sotzek <aliceks@google.com> 1597745207 +0200
committer Alice Kober-Sotzek <aliceks@google.com> 1599059749 +0200

Map ported comments to patchset-level comments on file deletion

Comments on files which are deleted in the target patchset should not
be simply dropped when we try to port them. Instead, we want to show
them in the next best location.

Before we had patchset-level comments, we intended to use the magic
/COMMIT_MSG file as fallback. With patchset-level comments, those seem
better suited. The only downside is that patchset-level comments don't
appear in the "Files" section (yet).

This change adapts GitPositionTransformer to explicitly handle positions
without file paths and to also support file deletions. The actual
mapping of a no-file position to a patchset-level comment is covered
by the previous change Idd4fbe961.

In theory, this change also fixes the handling of file deletions in the
context of edits due to rebase. It won't have any user-visible impact,
though, as there's no code path relating to edits due to rebase which
will have a different end result now. The reason for this is that we
filter the "mappings" early on with respect to touched files (outside of
GitPositionTransformer and EditTransformer) and hence only
non-deletion/non-addition mappings are given to GitPositionTransformer.

This change also adds a way to express a file addition as mapping. For
GitPositionTransformer, file additions are meaningless and simply
ignored. The API still allows to create such mappings as code paths
using GitPositionTransformer shouldn't need to care about such details
of the transformation algorithm. It's also simpler code wise to
translate all potential diff outcomes to a mapping instead of having to
add additional code for filtering of file additions outside of
GitPositionTransformer.

Change-Id: If8ed1e511a91651f228fc9515311bfd3c4df048d