2017-12-14 21:44:45 +00:00
|
|
|
#ifndef TRANSPORT_INTERNAL_H
|
|
|
|
#define TRANSPORT_INTERNAL_H
|
|
|
|
|
|
|
|
struct ref;
|
|
|
|
struct transport;
|
2018-03-15 17:31:22 +00:00
|
|
|
struct argv_array;
|
2017-12-14 21:44:45 +00:00
|
|
|
|
|
|
|
struct transport_vtable {
|
transport: list refs before fetch if necessary
The built-in bundle transport and the transport helper interface do not
work when transport_fetch_refs() is called immediately after transport
creation. This will be needed in a subsequent patch, so fix this.
Evidence: fetch_refs_from_bundle() relies on data->header being
initialized in get_refs_from_bundle(), and fetch() in transport-helper.c
relies on either data->fetch or data->import being set by get_helper(),
but neither transport_helper_init() nor fetch() calls get_helper().
Up until the introduction of the partial clone feature, this has not
been a problem, because transport_fetch_refs() is always called after
transport_get_remote_refs(). With the introduction of the partial clone
feature, which involves calling transport_fetch_refs() (to fetch objects
by their OIDs) without transport_get_remote_refs(), this is still not a
problem, but only coincidentally - we do not support partially cloning a
bundle, and as for cloning using a transport-helper-using protocol, it
so happens that before transport_fetch_refs() is called, fetch_refs() in
fetch-object.c calls transport_set_option(), which means that the
aforementioned get_helper() is invoked through set_helper_option() in
transport-helper.c.
This could be fixed by fixing the transports themselves, but it doesn't
seem like a good idea to me to open up previously untested code paths;
also, there may be transport helpers in the wild that assume that "list"
is always called before "fetch". Instead, fix this by having
transport_fetch_refs() call transport_get_remote_refs() to ensure that
the latter is always called at least once, unless the transport
explicitly states that it supports fetching without listing refs.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-27 19:24:06 +00:00
|
|
|
/**
|
|
|
|
* This transport supports the fetch() function being called
|
|
|
|
* without get_refs_list() first being called.
|
|
|
|
*/
|
|
|
|
unsigned fetch_without_list : 1;
|
|
|
|
|
2017-12-14 21:44:45 +00:00
|
|
|
/**
|
|
|
|
* Returns 0 if successful, positive if the option is not
|
|
|
|
* recognized or is inapplicable, and negative if the option
|
|
|
|
* is applicable but the value is invalid.
|
|
|
|
**/
|
|
|
|
int (*set_option)(struct transport *connection, const char *name,
|
|
|
|
const char *value);
|
|
|
|
/**
|
|
|
|
* Returns a list of the remote side's refs. In order to allow
|
|
|
|
* the transport to try to share connections, for_push is a
|
|
|
|
* hint as to whether the ultimate operation is a push or a fetch.
|
|
|
|
*
|
2018-03-15 17:31:22 +00:00
|
|
|
* If communicating using protocol v2 a list of prefixes can be
|
|
|
|
* provided to be sent to the server to enable it to limit the ref
|
|
|
|
* advertisement. Since ref filtering is done on the server's end, and
|
|
|
|
* only when using protocol v2, this list will be ignored when not
|
|
|
|
* using protocol v2 meaning this function can return refs which don't
|
|
|
|
* match the provided ref_prefixes.
|
|
|
|
*
|
2017-12-14 21:44:45 +00:00
|
|
|
* If the transport is able to determine the remote hash for
|
|
|
|
* the ref without a huge amount of effort, it should store it
|
|
|
|
* in the ref's old_sha1 field; otherwise it should be all 0.
|
|
|
|
**/
|
2018-03-15 17:31:22 +00:00
|
|
|
struct ref *(*get_refs_list)(struct transport *transport, int for_push,
|
|
|
|
const struct argv_array *ref_prefixes);
|
2017-12-14 21:44:45 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Fetch the objects for the given refs. Note that this gets
|
|
|
|
* an array, and should ignore the list structure.
|
|
|
|
*
|
|
|
|
* If the transport did not get hashes for refs in
|
|
|
|
* get_refs_list(), it should set the old_sha1 fields in the
|
|
|
|
* provided refs now.
|
|
|
|
**/
|
fetch-pack: unify ref in and out param
When a user fetches:
- at least one up-to-date ref and at least one non-up-to-date ref,
- using HTTP with protocol v0 (or something else that uses the fetch
command of a remote helper)
some refs might not be updated after the fetch.
This bug was introduced in commit 989b8c4452 ("fetch-pack: put shallow
info in output parameter", 2018-06-28) which allowed transports to
report the refs that they have fetched in a new out-parameter
"fetched_refs". If they do so, transport_fetch_refs() makes this
information available to its caller.
Users of "fetched_refs" rely on the following 3 properties:
(1) it is the complete list of refs that was passed to
transport_fetch_refs(),
(2) it has shallow information (REF_STATUS_REJECT_SHALLOW set if
relevant), and
(3) it has updated OIDs if ref-in-want was used (introduced after
989b8c4452).
In an effort to satisfy (1), whenever transport_fetch_refs()
filters the refs sent to the transport, it re-adds the filtered refs to
whatever the transport supplies before returning it to the user.
However, the implementation in 989b8c4452 unconditionally re-adds the
filtered refs without checking if the transport refrained from reporting
anything in "fetched_refs" (which it is allowed to do), resulting in an
incomplete list, no longer satisfying (1).
An earlier effort to resolve this [1] solved the issue by readding the
filtered refs only if the transport did not refrain from reporting in
"fetched_refs", but after further discussion, it seems that the better
solution is to revert the API change that introduced "fetched_refs".
This API change was first suggested as part of a ref-in-want
implementation that allowed for ref patterns and, thus, there could be
drastic differences between the input refs and the refs actually fetched
[2]; we eventually decided to only allow exact ref names, but this API
change remained even though its necessity was decreased.
Therefore, revert this API change by reverting commit 989b8c4452, and
make receive_wanted_refs() update the OIDs in the sought array (like how
update_shallow() updates shallow information in the sought array)
instead. A test is also included to show that the user-visible bug
discussed at the beginning of this commit message no longer exists.
[1] https://public-inbox.org/git/20180801171806.GA122458@google.com/
[2] https://public-inbox.org/git/86a128c5fb710a41791e7183207c4d64889f9307.1485381677.git.jonathantanmy@google.com/
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-01 20:13:20 +00:00
|
|
|
int (*fetch)(struct transport *transport, int refs_nr, struct ref **refs);
|
2017-12-14 21:44:45 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Push the objects and refs. Send the necessary objects, and
|
|
|
|
* then, for any refs where peer_ref is set and
|
|
|
|
* peer_ref->new_oid is different from old_oid, tell the
|
|
|
|
* remote side to update each ref in the list from old_oid to
|
|
|
|
* peer_ref->new_oid.
|
|
|
|
*
|
|
|
|
* Where possible, set the status for each ref appropriately.
|
|
|
|
*
|
|
|
|
* The transport must modify new_sha1 in the ref to the new
|
|
|
|
* value if the remote accepted the change. Note that this
|
|
|
|
* could be a different value from peer_ref->new_oid if the
|
|
|
|
* process involved generating new commits.
|
|
|
|
**/
|
|
|
|
int (*push_refs)(struct transport *transport, struct ref *refs, int flags);
|
|
|
|
int (*connect)(struct transport *connection, const char *name,
|
|
|
|
const char *executable, int fd[2]);
|
|
|
|
|
|
|
|
/** get_refs_list(), fetch(), and push_refs() can keep
|
|
|
|
* resources (such as a connection) reserved for further
|
|
|
|
* use. disconnect() releases these resources.
|
|
|
|
**/
|
|
|
|
int (*disconnect)(struct transport *connection);
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif
|