org.eclipse.jgit.transport

## Interface FetchConnection

All Superinterfaces:
  Connection

All Known Implementing Classes:
  BasePackFetchConnection

    public interface FetchConnection
    extends Connection

Lists known refs from the remote and copies objects of selected refs.

A fetch connection typically connects to the `git-upload-pack` service running where the remote repository is stored. This provides a one-way object transfer service to copy objects from the remote repository into this local repository.

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

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

See Also:
  `Transport`

### Method Summary

Methods
`boolean` `didFetchIncludeTags()` Did the last `fetch(ProgressMonitor, Collection, Set)` get tags?
`boolean` `didFetchTestConnectivity()` Did the last `fetch(ProgressMonitor, Collection, Set)` validate graph?
`void` `fetch(ProgressMonitor monitor, Collection<Ref> want, Set<ObjectId> have)` Fetch objects we don't have but that are reachable from advertised refs.
`void` `fetch(ProgressMonitor monitor, Collection<Ref> want, Set<ObjectId> have, OutputStream out)` Fetch objects we don't have but that are reachable from advertised refs.
`Collection<PackLock>` `getPackLocks()` All locks created by the last `fetch(ProgressMonitor, Collection, Set)` call.
`void` `setPackLockMessage(String message)` Set the lock message used when holding a pack out of garbage collection.

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

`close, getMessages, getRef, getRefs, getRefsMap`

### Method Detail

#### fetch

    void fetch(ProgressMonitor monitor,
             Collection<Ref> want,
             Set<ObjectId> have)
               throws TransportException

Fetch objects we don't have but that are reachable from advertised refs.

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

Implementations are free to use network connections as necessary to efficiently (for both client and server) transfer objects from the remote repository into this repository. When possible implementations should avoid replacing/overwriting/duplicating an object already available in the local destination repository. Locally available objects and packs should always be preferred over remotely available objects and packs. `Transport.isFetchThin()` should be honored if applicable.

Parameters:
  `monitor` - progress monitor to inform the end-user about the amount of work completed, or to indicate cancellation. Implementations should poll the monitor at regular intervals to look for cancellation requests from the user.
  `want` - one or more refs advertised by this connection that the caller wants to store locally.
  `have` - additional objects known to exist in the destination repository, especially if they aren't yet reachable by the ref database. Connections should take this set as an addition to what is reachable through all Refs, not in replace of it.
Throws:
  `TransportException` - objects could not be copied due to a network failure, protocol error, or error on remote side, or connection was already used for fetch.

#### fetch

    void fetch(ProgressMonitor monitor,
             Collection<Ref> want,
             Set<ObjectId> have,
             OutputStream out)
               throws TransportException

Fetch objects we don't have but that are reachable from advertised refs.

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

Implementations are free to use network connections as necessary to efficiently (for both client and server) transfer objects from the remote repository into this repository. When possible implementations should avoid replacing/overwriting/duplicating an object already available in the local destination repository. Locally available objects and packs should always be preferred over remotely available objects and packs. `Transport.isFetchThin()` should be honored if applicable.

Parameters:
  `monitor` - progress monitor to inform the end-user about the amount of work completed, or to indicate cancellation. Implementations should poll the monitor at regular intervals to look for cancellation requests from the user.
  `want` - one or more refs advertised by this connection that the caller wants to store locally.
  `have` - additional objects known to exist in the destination repository, especially if they aren't yet reachable by the ref database. Connections should take this set as an addition to what is reachable through all Refs, not in replace of it.
  `out` - OutputStream to write sideband messages to
Throws:
  `TransportException` - objects could not be copied due to a network failure, protocol error, or error on remote side, or connection was already used for fetch.
Since:
  3.0

#### didFetchIncludeTags

    boolean didFetchIncludeTags()

Did the last `fetch(ProgressMonitor, Collection, Set)` get tags?

Some Git aware transports are able to implicitly grab an annotated tag if `TagOpt.AUTO_FOLLOW` or `TagOpt.FETCH_TAGS` was selected and the object the tag peels to (references) was transferred as part of the last `fetch(ProgressMonitor, Collection, Set)` call. If it is possible for such tags to have been included in the transfer this method returns true, allowing the caller to attempt tag discovery.

By returning only true/false (and not the actual list of tags obtained) the transport itself does not need to be aware of whether or not tags were included in the transfer.

Returns:
  true if the last fetch call implicitly included tag objects; false if tags were not implicitly obtained.

#### didFetchTestConnectivity

    boolean didFetchTestConnectivity()

Did the last `fetch(ProgressMonitor, Collection, Set)` validate graph?

Some transports walk the object graph on the client side, with the client looking for what objects it is missing and requesting them individually from the remote peer. By virtue of completing the fetch call the client implicitly tested the object connectivity, as every object in the graph was either already local or was requested successfully from the peer. In such transports this method returns true.

Some transports assume the remote peer knows the Git object graph and is able to supply a fully connected graph to the client (although it may only be transferring the parts the client does not yet have). Its faster to assume such remote peers are well behaved and send the correct response to the client. In such transports this method returns false.

Returns:
  true if the last fetch had to perform a connectivity check on the client side in order to succeed; false if the last fetch assumed the remote peer supplied a complete graph.

#### setPackLockMessage

    void setPackLockMessage(String message)

Set the lock message used when holding a pack out of garbage collection.

Callers that set a lock message must ensure they call `getPackLocks()` after `fetch(ProgressMonitor, Collection, Set)`, even if an exception was thrown, and release the locks that are held.

Parameters:
  `message` - message to use when holding a pack in place.

#### getPackLocks

    Collection<PackLock> getPackLocks()

All locks created by the last `fetch(ProgressMonitor, Collection, Set)` call.

Returns:
  collection (possibly empty) of locks created by the last call to fetch. The caller must release these after refs are updated in order to safely permit garbage collection.