git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).