Re: [PATCH v3] Limit refs to fetch to minimum in shallow clones

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

 



Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:

> The main purpose of shallow clones is to reduce download by only
> fetching objects up to a certain depth from the given refs. The number
> of objects depend on how many refs to follow. So:
>
>  - Only fetch HEAD or the ref specified by --branch
>  - Only fetch tags that reference to downloaded objects
>
> More tags/branches can be fetched later using git-fetch as usual.
>
> The old behaviour can still be called with --no-single-branch
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---

Thanks.

> @@ -179,6 +180,15 @@ objects from the source repository into a pack in the cloned repository.
>  	with a long history, and would want to send in fixes
>  	as patches.
>  
> +--single-branch::
> +--no-single-branch::
> +	These options are only valid when --depth is given.
> +	 `--single-branch` only fetches one branch (either HEAD or
> +	specified by --branch) and tags that point to the downloaded
> +	history. `--no-single-branch` fetches all branches and tags
> +	like in normal clones. `--single-branch` is implied by
> +	default.
> +

My first reaction after reading "is implied by default" was "Huh? didn't
we just read these kick in only when --depth is given?" and I had to read
it again. Here is my attempt to rephrase it.

        Clone only the history leading to the tip of a single branch,
        either specified by the `--branch` option or the primary branch
        remote's `HEAD` points at. When creating a shallow clone with the
        `--depth` option, this is the default, unless `--no-single-branch`
        is given to fetch the histories near the tips of all branches.

        Currently this option only works when creating a shallow clone and
        does not have any effect without the `--depth` option.

We might want to later enhance this to work also with a full-depth clone
that tracks only one branch, and the above phrasing would make it clear.

> +		if (!option_branch)
> +			remote_head = guess_remote_head(head, refs, 0);
> +		else {
> +			struct strbuf sb = STRBUF_INIT;
> +			strbuf_addstr(&sb, src_ref_prefix);
> +			strbuf_addstr(&sb, option_branch);
> +			remote_head = find_ref_by_name(refs, sb.buf);
> +			strbuf_release(&sb);
> +		}
> +
> +		if (!remote_head)
> +			die(_("Remote branch \"%s\" not found. Nothing to clone.\n"
> +			      "Try --no-single-branch to fetch all refs."),
> +			    option_branch ? option_branch : "HEAD");

Switching upon option_branch to tweak the message is a good idea, but
strictly speaking, we would hit this die() when guess_remote_head() does
not find where HEAD points at because it is detached, and in that case,
the error is not "Nothing to clone", but "We couldn't tell which branch
you meant to limit this cloning to".

> @@ -642,9 +679,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>  
>  		transport_set_option(transport, TRANS_OPT_KEEP, "yes");
>  
> -		if (option_depth)
> +		if (option_depth) {
>  			transport_set_option(transport, TRANS_OPT_DEPTH,
>  					     option_depth);
> +			transport_set_option(transport, TRANS_OPT_FOLLOWTAGS,
> +					     option_single_branch ? "1" : NULL);

Curious. Does anybody set FOLLOWTAGS to the transport by default becore we
come here (just asking)?
--
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]