All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Krey <a.krey@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 2/3] connect.c: save symref info from server capabilities
Date: Fri, 6 Sep 2013 21:25:15 +0200	[thread overview]
Message-ID: <20130906192515.GI12966@inner.h.apk.li> (raw)
In-Reply-To: <xmqqob85ygt8.fsf@gitster.dls.corp.google.com>

On Fri, 06 Sep 2013 10:56:51 +0000, Junio C Hamano wrote:
> Andreas Krey <a.krey@gmx.de> writes:
> 
...
> > +		if (symref) {
> > +			ref->symref = xcalloc(symref_len + 1, 1);
> > +			strncpy(ref->symref, symref, symref_len);
> > +		}
...
> 
> This looks utterly wrong.  HEAD may happen to be the first ref that
> is advertised and hence capability list typically comes on it, but
> that does not necessarily have to be the case from the protocol's
> correctness point of view.

Ok, then I misunderstood that part. I thought we'd be going to
put the symref (if any) into 'capabilities' on the respective ref,
but putting them all in one capability list sounds saner all in all.

> I think this function should do this instead.
> 
>     - inside the loop, collect the "symref=..." capabilities;
> 
>     - after the loop, look at the "symref=..." capabilities, and
>       among the refs the loop added to the *list, find the "HEAD"
>       ref and set its ->symref to point at an appropirate ref.

Fair game. There goes the parse_feature_value; will have to iterate
another way (or look them ("symref=#{name}:") up instead of collecting
them into a hash beforehand).

Can I assume that the only capability list is always on the
first ref sent (as it is now)?

(And besides, is there something more suitable for the 
 xcalloc/strncpy combination?)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

  reply	other threads:[~2013-09-06 19:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 15:52 [PATCH 0/3] Unconfuse git clone when two branches at are HEAD Andreas Krey
2013-09-06 15:56 ` [PATCH 1/3] upload-pack: send the HEAD information Andreas Krey
2013-09-06 17:46   ` Junio C Hamano
2013-09-06 19:29     ` Andreas Krey
2013-09-06 19:54       ` Junio C Hamano
2013-09-08  7:13     ` Jeff King
2013-09-08  7:22       ` Jeff King
2013-09-08 17:27       ` Junio C Hamano
2013-09-18  2:31   ` [PATCH v2 0/6] Removing the guesswork of HEAD in "clone" Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 1/6] upload-pack.c: do not pass confusing cb_data to mark_our_ref() Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 2/6] upload-pack: send symbolic ref information as capability Junio C Hamano
2013-09-18  4:36       ` Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 3/6] upload-pack: send non-HEAD symbolic refs Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 4/6] connect.c: make parse_feature_value() static Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 5/6] connect: annotate refs with their symref information in get_remote_head() Junio C Hamano
2013-09-18  2:31     ` [PATCH v2 6/6] clone: test the new HEAD detection logic Junio C Hamano
2013-09-06 15:56 ` [PATCH 2/3] connect.c: save symref info from server capabilities Andreas Krey
2013-09-06 17:56   ` Junio C Hamano
2013-09-06 19:25     ` Andreas Krey [this message]
2013-09-06 19:46       ` Junio C Hamano
2013-09-06 15:57 ` [PATCH 3/3] clone: test the new HEAD detection logic Andreas Krey
2013-09-06 17:29 ` [PATCH 0/3] Unconfuse git clone when two branches at are HEAD Philip Oakley
2013-09-06 18:17   ` Junio C Hamano
2013-09-06 23:19     ` Philip Oakley
2013-09-07 15:50       ` Junio C Hamano
2013-09-07 19:19         ` Philip Oakley
2013-09-08 17:35           ` Junio C Hamano
2013-09-08 21:00             ` Philip Oakley
2013-09-09 14:44               ` Junio C Hamano
2013-09-09 16:08                 ` Andreas Krey
2013-09-09 22:20                 ` Philip Oakley
2013-09-09 22:26                   ` Junio C Hamano

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=20130906192515.GI12966@inner.h.apk.li \
    --to=a.krey@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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.