commit 518d3ddffc760a15634775c380d3a506085d71cf
author David Pursehouse <dpursehouse@digital.ai> Fri May 15 09:49:23 2020 +0900
committer Gerrit Code Review <noreply-gerritcodereview@google.com> Fri May 15 00:49:23 2020 +0000
tree ce4530a51f65ec083f4a43c8b969900af76505a6
parent 9c85f555854c72b24fa4f69a46a0174dc5a68cd5

Update git submodules

* 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