git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jamey Sharp <jamey@minilop.net>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <johannes.sixt@telecom.at>,
	Jeff King <peff@peff.net>, Josh Triplett <josh@joshtriplett.org>
Subject: Re: [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack
Date: Thu, 02 Jun 2011 16:05:23 -0700	[thread overview]
Message-ID: <7v8vtjdebw.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1306887870-3875-3-git-send-email-jamey@minilop.net> (Jamey Sharp's message of "Tue, 31 May 2011 17:24:29 -0700")

Jamey Sharp <jamey@minilop.net> writes:

> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index e1a687a..9bb268a 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -109,6 +109,7 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
>  
>  static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
>  {
> +	path = path ? strip_namespace(path) : "capabilities^{}";
>  	if (sent_capabilities)
>  		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
>  	else

This feels really ugly.

Logically the stripping of "path" should happen before the caller calls
this function, as the purpose of this function is "given a token and
object name, produce one line of 'I have this at here' protocol message,
which is defined to have the capability list tucked after the first of
such messages in an exchange". It now is "the token has to be a path in a
namespace; the only exception is when the token is NULL, in which case we
always send 'capabilities^{}'".

It also is a very selfish solution for an immediate issue(*) that does not
give much considertation for people who may want to add new things in the
future, as the _only_ possible special case is to send in NULL.

The immediate issue you wanted to solve, I think, is that it is not
convenient to strip in the caller as this is a callback. Still, I think it
should be easy to do something like...

	static int show_ref_message(const char *path,
        				 const unsigned char *sha1)
	{
		... original show_ref() implementation comes here ...
	}

        static int show_ref_cb(const char *path,
			        const unsigned char *sha1,
                                int flag, void *cb_data)
	{
		return show_ref_message(strip_namespace(path), sha1);
        }
        
and give the latter as the callback to for_each_ref_in_namespace().

And the call to run "capabilities^{}" when there is no ref can call
show_ref_message() directly.

  reply	other threads:[~2011-06-02 23:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-01  0:24 [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers Jamey Sharp
2011-06-01  0:24 ` [PATCHv4 2/4] Add infrastructure for ref namespaces Jamey Sharp
2011-06-02 22:44   ` Junio C Hamano
2011-06-02 23:36     ` Josh Triplett
2011-06-03  2:51       ` Junio C Hamano
2011-06-03 17:26         ` Josh Triplett
2011-06-03  8:35   ` Jakub Narebski
2011-06-03 21:01     ` Josh Triplett
2011-06-08  9:41       ` Jakub Narebski
2011-06-09  3:38         ` Josh Triplett
2011-06-09  9:09           ` Jakub Narebski
2011-06-01  0:24 ` [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack Jamey Sharp
2011-06-02 23:05   ` Junio C Hamano [this message]
2011-06-03  0:06     ` josh
2011-06-03 16:33       ` Junio C Hamano
2011-06-01  0:24 ` [PATCHv4 4/4] Add documentation for ref namespaces Jamey Sharp
2011-06-02 20:36 ` [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers Junio C Hamano
2011-06-02 20:57   ` Josh Triplett
2011-06-02 23:29     ` Junio C Hamano
2011-06-03  8:33 ` Jakub Narebski

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=7v8vtjdebw.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jamey@minilop.net \
    --cc=johannes.sixt@telecom.at \
    --cc=josh@joshtriplett.org \
    --cc=peff@peff.net \
    --cc=spearce@spearce.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 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).