From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] Document details of transport function APIs
Date: Tue, 24 Mar 2009 23:47:06 -0700 [thread overview]
Message-ID: <7v63hy9k0l.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0903242303250.19665@iabervon.org> (Daniel Barkalow's message of "Tue, 24 Mar 2009 23:04:10 -0400 (EDT)")
Daniel Barkalow <barkalow@iabervon.org> writes:
> In particular, explain which of the fields of struct ref is used for
> what purpose in the input to and output from each function.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
> ---
> transport.h | 38 ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/transport.h b/transport.h
> index 489e96a..2e1650a 100644
> --- a/transport.h
> +++ b/transport.h
> @@ -18,11 +18,49 @@ struct transport {
> 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.
> + *
It is unclear what this "hint" is intended to be used for, what the
transport is and isn't allowed to use it for, and what existing transports
typically use it for.
> + /**
> + * Push the objects and refs. Send the necessary objects, and
> + * then tell the remote side to update each ref in the list
> + * from old_sha1 to new_sha1.
> + *
> + * Where possible, set the status for each ref appropriately.
> + *
> + * If, in the process, the transport determines that the
> + * remote side actually responded to the push by updating the
> + * ref to a different value, the transport should modify the
> + * new_sha1 in the ref. (Note that this is a matter of the
> + * remote accepting but rewriting the change, not rejecting it
> + * and reporting that a different update had already taken
> + * place)
> + **/
It this even a sane thing to allow? How would it interact with the
"pretend we immediately turned around and fetched them into the remote
tracking branches" local updates we usually do?
> int (*push_refs)(struct transport *transport, struct ref *refs, int flags);
> int (*push)(struct transport *connection, int refspec_nr, const char **refspec, int flags);
>
> + /** get_refs_list(), fetch(), and push_refs() can keep
> + * resources (such as a connection) reserved for futher
> + * use. disconnect() releases these resources.
> + **/
> int (*disconnect)(struct transport *connection);
> char *pack_lockfile;
> signed verbose : 2;
It is just a style thing, but all of our multi-line comments are
/*
* of
* this
* form
*/
and these new comments are formatted slightly differently with double
asterisks on only the first and the last lines. In addition, th last
comment block uses a yet another different style, which is a bit of
eyesore.
next prev parent reply other threads:[~2009-03-25 6:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 3:04 [PATCH 2/5] Document details of transport function APIs Daniel Barkalow
2009-03-25 6:47 ` Junio C Hamano [this message]
2009-03-25 16:19 ` Daniel Barkalow
2009-03-25 18:03 ` Junio C Hamano
2009-03-25 18:42 ` Daniel Barkalow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v63hy9k0l.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.