Re: [PATCH 2/2] upload-pack: fix off-by-one depth calculation in shallow clone

[Junio C Hamano <gitster@pobox.com>]

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

> get_shallow_commits() is used to determine the cut points at a given
> depth (i.e. the number of commits in a chain that the user likes to
> get). However we count current depth up to the commit "commit" but we
> do the cutting at its parents (i.e. current depth + 1). This makes
> upload-pack always return one commit more than requested. This patch
> fixes it.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  shallow.c             |  8 +++++++-
>  t/t5500-fetch-pack.sh | 25 +++++++++++++++++++------
>  2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/shallow.c b/shallow.c
> index a0363de..6be915f 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -72,8 +72,14 @@ struct commit_list *get_shallow_commits(struct object_array *heads, int depth,
>  		}
>  		if (parse_commit(commit))
>  			die("invalid commit");
> -		commit->object.flags |= not_shallow_flag;
>  		cur_depth++;
> +		if (cur_depth >= depth) {
> +			commit_list_insert(commit, &result);
> +			commit->object.flags |= shallow_flag;
> +			commit = NULL;
> +			continue;
> +		}
> +		commit->object.flags |= not_shallow_flag;
>  		for (p = commit->parents, commit = NULL; p; p = p->next) {
>  			if (!p->item->util) {
>  				int *pointer = xmalloc(sizeof(int));

Nice.  No protocol extensions, you update the server side, and an
old client starts getting the right number of generations.

> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index 6a6e672..58d3bdf 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -130,16 +130,25 @@ test_expect_success 'single given branch clone' '
>  	test_must_fail git --git-dir=branch-a/.git rev-parse origin/B
>  '
>  
> +test_expect_success 'clone shallow depth 1' '
> +	git clone --no-single-branch --depth 1 "file://$(pwd)/." shallow0
> +	test "`git --git-dir=shallow0/.git rev-list --count HEAD`" = 1
> +'

No &&-chaining?

Thanks.