The diff between two patch sets contains hunks which weren't
introduced by either patch set if a rebase occurred between those
patch sets. Previous optimizations for this case simply omitted all
files which aren't touched by either of the patch sets.
This change goes one step further: All hunks which can clearly be
identified as being introduced by a rebase are marked. In case of
doubt (e.g. they overlap with a regular hunk), they aren't marked.
To be consistent with the previous behavior, we exclude all files from
the result which only contain hunks due to rebase. In some cases (e.g.
a patch set touches 'fileA' but all identified hunks were introduced
by the rebase), this rule can be stricter than the previously mentioned
(as the previous rule would still show file 'fileA' but we exclude it
now).
Hunks which are introduced by a rebase are identified by computing
the diff between the parents of the two patch sets and transforming
the result to differences in terms of treeA of patch set A and treeB
of patch set B. This follows a suggestion which was posted as a comment
(https://gerrit-review.googlesource.com/c/33091/5//COMMIT_MSG#7) in
change I63d3a21ad4f.
As we always determine which hunks are introduced by a rebase when
two commits are explicitly specified which don't share a common
parent, we will determine those hunks even when we compute the
diff between the parents of the patch sets provided that those
parents fulfill the condition of being separated by a rebase. Those
situations should be rare and hence we refrain from adding
optimizations for this case for the moment.
Bug: Issue 217
Change-Id: If06381d506d360f0e3d24d078dcb54692698e766
To apply a suggested fix, we manually compute the Git tree which
results from applying the described modifications to the patch set.
That Git tree is transformed into a change edit if none exists or
merged with an existing one.
Similar to change edits, fixes may only be applied for the current
patch set if no change edit exists. If one exists, fixes may only be
applied for the patch set on which the change edit is based on.
To fail as early as possible, we now reject suggested fixes which
include overlapping replacements when they are provided as review input.
Change-Id: Iabf0d0af025b0878e839956d16f29693b1e74eee
Convert the tests to use Google Truth instead of junit.Assert.
Add a new PathSubject to perform assertions about Path objects.
Change-Id: I8016daeebc6f8cb291f9a767441f5e1a52ea5097
Having a standard tool for formatting saves reviewers' valuable time.
google-java-format is Google's standard formatter and is somewhat
inspired by gofmt[1]. This commit formats everything using
google-java-format version 1.2.
The downside of this one-off formatting is breaking blame. This can be
somewhat hacked around with a tool like git-hyper-blame[2], but it's
definitely not optimal until/unless this kind of feature makes its way
to git core.
Not in this change:
* Tool support, e.g. Eclipse. The command must be run manually [3].
* Documentation of best practice, e.g. new 100-column default.
[1] https://talks.golang.org/2015/gofmt-en.slide#3
[2] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[3] git ls-files | grep java$ | xargs google-java-format -i
Change-Id: Id5f3c6de95ce0b68b41f0a478b5c99a93675aaa3
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
For some reason, a Java API for change edits didn't exist previously
even though a detailed REST API has been available. Because of that,
tests needed to use internal classes when they interacted with change
edits. Using internal classes is fragile and impedes refactorings.
That's why we should avoid it.
If possible, the structure and behavior of the tests is kept. Some of
them might and should be improved but that's beyond the scope of this
change. Some of the tests are adapted a bit because the internal
classes allow change edits to be created for previous patch sets
which isn't possible when using the REST API (and hence the Java API).
As modifications to the mentioned internal classes are necessary to
properly implement the 'Apply fix' feature of robot comments, it is
crucial that none of the tests use the internal classes directly.
In addition, the tests which will be added for the 'Apply fix' feature
will also need to modify and query change edits, which will be much
easier with the Java API.
Change-Id: I6b455541d1bc1b7a05b5f0507911181b0451829a
Up to now, the file path was implicitly limited to the file on which
the robot comment was placed. This restriction will be relaxed in the
future. In order to not break systems which use the fix suggestions at
that (later) point in time, the mandatory field 'path' is introduced
with this change.
Change-Id: I73875b97bf844dee927720765046161bbd888c02
To simplify and encourage writing unit tests, the custom Truth subjects
are moved to a Bazel/Buck package which is available to the IT tests as
well as the unit tests.
Change-Id: I529bfa5e8b566a17a05a2ba33c884655bb454dcf
In order to use the RangeSubject within gerrit-extension-api as well
as gerrit-acceptance-tests, a new Bazel/Buck package is introduced.
The purpose of this package is to bundle test helper classes which are
shared by different packages.
Change-Id: I59aa42d89c06f4de60a2a05d41a72653eba268de
