Re: [PATCH] clone: make sure we support the transport type
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- May 27, 2008, 18:05 UTC
- Message-ID
- <alpine.LNX.1.00.0805271352070.19665@iabervon.org>
- In-Reply-To
- <20080527142842.GA7651@sigill.intra.peff.net>
On Tue, 27 May 2008, Jeff King wrote:
Show 7 quoted lines
> If we use an unsupported transport (e.g., http when curl > support is not compiled in), transport_get reports an error > to the user, but we still get a transport object. We need to > manually check and abort the clone process at that point, or > we end up with a segfault. > > Noticed by Thomas Rast.
Good catch. I think it might be better to have the transport functions report failure when the method requested is NULL, but it's also worthwhile to notice this in advance and give the user a comprehensive message in advance.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Show 31 quoted lines
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> There are a few other calls to transport_get in builtin-clone, for
> setting up references and doing local cloning. I didn't check, but
> assumed it was impossible for http:// remotes to make it to that code
> path.
>
> builtin-clone.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index 4740b13..f4accbe 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -449,6 +449,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> struct remote *remote = remote_get(argv[0]);
> struct transport *transport = transport_get(remote, argv[0]);
>
> + if (!transport->get_refs_list || !transport->fetch)
> + die("Don't know how to clone %s", transport->url);
> +
> transport_set_option(transport, TRANS_OPT_KEEP, "yes");
>
> if (option_depth)
> --
> 1.5.6.rc0.128.g5fd3b9.dirty
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>