Update git submodules
* Update plugins/replication from branch 'master' to d87fe964ed71f002e2bde2478bf2a9099ed627ff - Merge branch 'stable-3.1' * stable-3.1: 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: Ifd3eaa962ea0a3ec81f827e244bed2c303cd1419 - Merge branch 'stable-3.0' into stable-3.1 * stable-3.0: 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: I7d5ecbedad8f061c0f6d44b38ba18322bea19c78 - 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
This commit is contained in:

committed by
Gerrit Code Review

parent
2668d065e1
commit
c7a061eead