Currently in a circular dependency for the same project, the origin
remote points to an arbitrary change within the cycle. For example,
in a queue with two items, the second one being a cycle:
[ d c b ] -> [ a ] -> HEAD
The jobs for the d, c, b cycle will all have their origin point to
a merge commit for b (whose parent will be a merge commit for c)
if d triggered the change.
This is not useful for a case where a user might want to examine only
one change out of the cycle since the "parent" at the origin is chosen
arbitrarily and is used for all the jobs in the cycle.
Our exemplar use-case for the origin remote is a linter job. When we
consider how a linter job might be used in a dependency cycle, it would
either be to lint a single change in the cycle, or to lint the cycle
collectively (in which case the job could be deduplicated). In both
cases, having the origin remote point to the state before the first change
in the cycle was merged would be useful. In this case, the deduplicated
collective linter job could make no changes and diffing from origin..HEAD
would be correct. A linter job for individual changes could re-do the
merge with only its change based on the origin (this is not great, and
the other choice is much better).
Change-Id: I16dc73b79aa4ddfe8b3683687b26daf8e8acae7a
17b1f13d26