* Update plugins/replication from branch 'stable-3.0'
to 1f0fe75b94b94e99aaa52b65c0fbdf525ccf8560
- Merge branch 'stable-2.16' into stable-3.0
* stable-2.16:
PushOne: Improve format of log of references to be pushed
Don't lose state when there's a pending push to the same ref
Change-Id: I78a3f0ff2e596a88d162fbe84caa1282ca1589f6
- PushOne: Improve format of log of references to be pushed
The references to be pushed are logged by just passing the list
of RemoteRefUpdate instances to the logger. This results in the
List's default implementation of toString() being called, which
renders each object in a comma-separated list.
Each object is rendered by RemoteRefUpdate's toString() method
which includes some fields that are not relevant here, or omits
some information that might be useful. For example:
[RemoteRefUpdate[remoteName=refs/meta/config, NOT_ATTEMPTED,
(null)...a7038eb8827cfd29cb3fca335e882f4d5ed09b62, srcRef=refs/meta/config,
forceUpdate, message=null]
- The 'remoteName' is the name on the destination. In this case it's
the same as 'srcRef' but could be different if replication has been
configured to push to a different refname. It is potentially confusing
to have them not logged next to each other.
- '(null)...a7038eb8827cfd29cb3fca335e882f4d5ed09b62' shows the old
and new IDs; this is in the standard git ref update format aside
from '(null)' which is shown instead of zeros.
- 'forceUpdate' is only included when true; this is the same for
the 'fastForward' field.
- the update has a flag indicating if it's a delete, but this is
not included in the output at all.
- 'message' is always null for udates by replication so it's not
necessary to include in the log.
Add a custom method to format the refs for logging, with the information
presented in a clearer way. Continue to log it on a single line, comma-
separated. This might not be ideal for human readers, but makes it easier
when processing the logs with grep or any other tool.
With this change, the logged information looks like:
RemoteRefUpdate{refSpec=refs/meta/config:refs/meta/config,
status=NOT_ATTEMPTED, id=(null)..a7038eb8827cfd29cb3fca335e882f4d5ed09b62
force=yes, delete=no, ffwd=no}
Now the irrelevant information (message) is removed, missing information
(delete) is added, and the source and destination refs are presented in
a single "refSpec" field.
Change-Id: Idd153daf44cd79a0920ea0b72c64ea58d0926f59
- Don't lose state when there's a pending push to the same ref
Previously if there was already a pending push (not an in-flight push)
to the same endpoint, the start for the push would be dropped when
adding the push to the Destination. This meant that a replication start
--wait command would never complete when one of its pushes was pending
since its state would never receive the completion notification for that
push.
Fix this by always adding the state and the ref in the Destination class
and preventing the duplicate "addRef" log message in the PushOne class.
Bug: Issue 12731
Change-Id: I33e6af2709bc38aac791a2f60fd896492167bbf5
518d3ddffc