org.eclipse.jgit.transport

## Interface PushConnection

All Superinterfaces:
  Connection

All Known Implementing Classes:
  BasePackPushConnection

    public interface PushConnection
    extends Connection

Lists known refs from the remote and sends objects to the remote.

A push connection typically connects to the `git-receive-pack` service running where the remote repository is stored. This provides a one-way object transfer service to copy objects from the local repository into the remote repository, as well as a way to modify the refs stored by the remote repository.

Instances of a PushConnection must be created by a `Transport` that implements a specific object transfer protocol that both sides of the connection understand.

PushConnection instances are not thread safe and may be accessed by only one thread at a time.

See Also:
  `Transport`

### Method Summary

All Methods Instance Methods Abstract Methods
`void` `push(ProgressMonitor monitor, Map<String,RemoteRefUpdate> refUpdates)` Pushes to the remote repository basing on provided specification.
`void` `push(ProgressMonitor monitor, Map<String,RemoteRefUpdate> refUpdates, OutputStream out)` Pushes to the remote repository basing on provided specification.

### Methods inherited from interface org.eclipse.jgit.transport.Connection

`close, getMessages, getRef, getRefs, getRefsMap`

### Method Detail

#### push

    void push(ProgressMonitor monitor,
              Map<String,RemoteRefUpdate> refUpdates)
       throws TransportException

Pushes to the remote repository basing on provided specification. This possibly result in update/creation/deletion of refs on remote repository and sending objects that remote repository need to have a consistent objects graph from new refs.

Only one call per connection is allowed. Subsequent calls will result in `TransportException`.

Implementation may use local repository to send a minimum set of objects needed by remote repository in efficient way. `Transport.isPushThin()` should be honored if applicable. refUpdates should be filled with information about status of each update.

Parameters:
  `monitor` - progress monitor to update the end-user about the amount of work completed, or to indicate cancellation. Implementors should poll the monitor at regular intervals to look for cancellation requests from the user.
  `refUpdates` - map of remote refnames to remote refs update specifications/statuses. Can't be empty. This indicate what refs caller want to update on remote side. Only refs updates with `RemoteRefUpdate.Status.NOT_ATTEMPTED` should passed. Implementation must ensure that and appropriate status with optional message should be set during call. No refUpdate with `RemoteRefUpdate.Status.AWAITING_REPORT` or `RemoteRefUpdate.Status.NOT_ATTEMPTED` can be leaved by implementation after return from this call.
Throws:
  `TransportException` - objects could not be copied due to a network failure, critical protocol error, or error on remote side, or connection was already used for push - new connection must be created. Non-critical errors concerning only isolated refs should be placed in refUpdates.

#### push

    void push(ProgressMonitor monitor,
              Map<String,RemoteRefUpdate> refUpdates,
              OutputStream out)
       throws TransportException

Pushes to the remote repository basing on provided specification. This possibly result in update/creation/deletion of refs on remote repository and sending objects that remote repository need to have a consistent objects graph from new refs.

Only one call per connection is allowed. Subsequent calls will result in `TransportException`.

Implementation may use local repository to send a minimum set of objects needed by remote repository in efficient way. `Transport.isPushThin()` should be honored if applicable. refUpdates should be filled with information about status of each update.

Parameters:
  `monitor` - progress monitor to update the end-user about the amount of work completed, or to indicate cancellation. Implementors should poll the monitor at regular intervals to look for cancellation requests from the user.
  `refUpdates` - map of remote refnames to remote refs update specifications/statuses. Can't be empty. This indicate what refs caller want to update on remote side. Only refs updates with `RemoteRefUpdate.Status.NOT_ATTEMPTED` should passed. Implementation must ensure that and appropriate status with optional message should be set during call. No refUpdate with `RemoteRefUpdate.Status.AWAITING_REPORT` or `RemoteRefUpdate.Status.NOT_ATTEMPTED` can be leaved by implementation after return from this call.
  `out` - output stream to write sideband messages to
Throws:
  `TransportException` - objects could not be copied due to a network failure, critical protocol error, or error on remote side, or connection was already used for push - new connection must be created. Non-critical errors concerning only isolated refs should be placed in refUpdates.
Since:
  3.0