From: Jonathan Nieder <jrnieder@gmail.com>
To: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>
Cc: git@vger.kernel.org, David Michael Barr <davidbarr@google.com>,
Jeff King <peff@peff.net>,
Michael Haggerty <mhagger@alum.mit.edu>,
Sverre Rabbelier <srabbelier@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] Add explanatory comment for transport-helpers refs mapping.
Date: Tue, 17 Jul 2012 11:04:29 -0500 [thread overview]
Message-ID: <20120717160429.GG3071@burratino> (raw)
In-Reply-To: <13702454.DmcNg44yyH@flobuntu>
Hi,
Florian Achleitner wrote:
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -484,8 +484,18 @@ static int fetch_with_import(struct transport *transport,
> if (posn->status & REF_STATUS_UPTODATE)
> continue;
> if (data->refspecs)
> + /*
> + * If the remote-helper advertised the refpec capability, we
> + * retrieve the local, private ref from it. The imported data is
> + * expected there. (see Documentation/git-remote-helpers.*).
> + */
> private = apply_refspecs(data->refspecs, data->refspec_nr, posn-
>>name);
> else
> + /*
> + * else, the default refspec *:* is implied. The remote-helper has
> + * to import the remote heads directly to the local heads.
> + * remote-helpers using 'import' should have the refspec capability.
> + */
> private = xstrdup(posn->name);
What is _exactly_ the information the reader would want to know here?
Looking at this code:
char *private;
posn = to_fetch[i];
if (posn->status & REF_STATUS_UPTODATE)
continue;
if (!data->refspecs)
private = xstrdup(...);
else
private = apply_refspecs(...);
if (!private)
continue;
read_ref(private, posn->old_sha1);
free(private);
Despite the misleading "old_sha1" name, this loop runs after
fast-import has finished, and the values being read into
to_fetch[]::old_sha1 are object names representing the result.
Callers such as builtin/fetch.c then use these values to write
feedback to the terminal, to populate FETCH_HEAD, and to
determine what new value peer_ref should get.
Shouldn't the comment say something about these SHA-1s not actually
being old? Something like:
/*
* If the remote helper advertised the "refspec" capability,
* it will have the written result of the import to the refs
* named on the right hand side of the first refspec matching
* each ref we were fetching.
*
* (If no "refspec" capability was specified, for historical
* reasons we default to *:*.)
*
* Store the result in to_fetch[i].old_sha1. Callers such
* as "git fetch" can use the value to write feedback to the
* terminal, populate FETCH_HEAD, and determine what new value
* should be written to peer_ref if the update is a
* fast-forward or this is a forced update.
*/
for (i = 0; ...
Hmm?
Jonathan
prev parent reply other threads:[~2012-07-17 16:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 13:38 [RFC/PATCH 0/4] GSOC remote-svn Florian Achleitner
2012-07-11 13:38 ` [PATCH 1/4] vcs-svn: add fast_export_note to create notes Florian Achleitner
2012-07-11 13:38 ` [PATCH 2/4] Allow reading svn dumps from files via file:// urls Florian Achleitner
2012-07-11 13:38 ` [PATCH 3/4] Create a note for every imported commit containing svn metadata Florian Achleitner
2012-07-11 13:38 ` [PATCH 4/4] When debug==1, start fast-import with "--stats" instead of "--quiet" Florian Achleitner
2012-07-11 14:29 ` [PATCH 2/4] Allow reading svn dumps from files via file:// urls Dmitry Ivankov
2012-07-11 17:00 ` Junio C Hamano
2012-07-11 17:49 ` Stephen Bash
2012-07-15 14:26 ` [PATCH] Fix overwritten remote ref on with fast-import Florian Achleitner
2012-07-16 0:30 ` Jonathan Nieder
2012-07-16 4:33 ` Junio C Hamano
2012-07-16 22:33 ` Florian Achleitner
2012-07-17 3:27 ` Jonathan Nieder
2012-07-17 9:54 ` Florian Achleitner
2012-07-17 13:48 ` Jonathan Nieder
2012-07-17 20:52 ` Florian Achleitner
2012-07-17 21:02 ` Jonathan Nieder
2012-07-17 22:25 ` Florian Achleitner
2012-07-17 9:56 ` [PATCH] Add explanatory comment for transport-helpers refs mapping Florian Achleitner
2012-07-17 16:04 ` Jonathan Nieder [this message]
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=20120717160429.GG3071@burratino \
--to=jrnieder@gmail.com \
--cc=davidbarr@google.com \
--cc=florian.achleitner.2.6.31@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=srabbelier@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).