org.eclipse.jgit.transport

Interface FetchConnection

All Superinterfaces:

AutoCloseable, 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

Modifier and Type	Method and Description
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, getPeerUserAgent, 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.