[RFH] lifetime rule for url parameter to transport_get()?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Does anybody remember why we use a copied string of "ref_git_copy" in
builtin/clone.c::setup_reference()?

	ref_git = real_path(option_reference);
	...
	ref_git_copy = xstrdup(ref_git);
	add_to_alternates_file(ref_git_copy);
	remote = remote_get(ref_git_copy);
	transport = transport_get(remote, ref_git_copy);
	for (extra = transport_get_remote_refs(transport); extra;
	     extra = extra->next)
		add_extra_ref(extra->name, extra->old_sha1, 0);
	transport_disconnect(transport);
	free(ref_git_copy);

The three functions add_to_alternates_file(), remote_get(), and
transport_get() all get "const char *" so I do not think the copy was done
to avoid "option_reference" from getting clobbered by these functions. The
only thing I can think of is that transport_get() does this:

    struct transport *transport_get(struct remote *remote, const char *url)
    {
            const char *helper;
            struct transport *ret = xcalloc(1, sizeof(*ret));

            ...
            if (!url && remote->url)
                    url = remote->url[0];
            ret->url = url;
	    ...
	    return ret;
    }

holding onto "url" without making a copy for its own use. But then freeing
that copy by the caller after calling transport_disconnect() does not make
much sense to me---we could have just gave it the original option_reference,
have transport use it while it runs ls-remote equivalent, and then called
transport_disconnect(), without using any extra copy.

What I am missing?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]