Re: [PATCH v4] Do not decode url protocol.

[Jeff King <peff@peff.net>]

On Tue, Jun 22, 2010 at 10:16:57PM +0200, Pascal Obry wrote:

> When using the protocol git+ssh:// for example we do not want to
> decode the '+' as a space. The url decoding must take place only
> for the server name and parameters.
> 
> This fixes a regression introduced in 9d2e942.

Sorry, this is completely my fault. I obviously didn't test with
git+ssh. I looked at adding a new test case, but I don't think there's
an easy way. The only way to trigger it is by using "git+ssh" or
"ssh+git"; any other protocol (real or fake) will be handled by a custom
protocol handler and won't execute this broken code at all.

The patch looks reasonable (and I agree with all of Matthieu's comments
thus far). With respect to the "what if there is no slash" issue
discussed earlier, I prefer to be a bit defensive about possible inputs
in library-ish functions like this. But:

> +
> +       /* Skip protocol if present. */
> +       if (with_protocol) {
> +         first_slash = strchr(*query, '/');
> +
> +         while (q < first_slash)
> +               strbuf_addch(&out, *q++);
> +       }
> +

I think this actually works OK, given that "q < first_slash" will be
false if first_slash is NULL, assuming NULL is all-bytes-zero or some
low number (which is not guaranteed by the standard, but is a pretty
practical assumption these days).

However, you could make things a little more efficient by handing the
whole thing to strbuf at once:

  if (with_protocol) {
          const char *first_slash = strchr(q, '/');
          if (first_slash) {
                  strbuf_add(&out, q, first_slash - q);
                  q = first_slash;
          }
  }

which of course needs first_slash to be checked explicitly.  Not that
the efficiency probably matters in practice.

-Peff