From: Junio C Hamano <gitster@pobox.com>
To: Rong Bao <rong.bao@csmantle.top>
Cc: git@vger.kernel.org, Mingcong Bai <jeffbai@aosc.io>,
Rong Bao <baorong2005@126.com>, Tamino Bauknecht <dev@tb6.eu>
Subject: Re: [PATCH] fetch: fix --depth= and --unshallow for multi-remote fetches
Date: Thu, 15 Oct 2026 13:03:32 -0700 [thread overview]
Message-ID: <xmqq1p9qn33f.fsf@gitster.g> (raw)
In-Reply-To: <20261013144441.1632978-1-rong.bao@csmantle.top> (Rong Bao's message of "Tue, 13 Oct 2026 22:44:39 +0800")
Rong Bao <rong.bao@csmantle.top> writes:
> When running `git fetch --all --depth=<SOME-DEPTH>` or `git fetch --all
> --unshallow` with Git 2.56.0, the fetch isn't really deepened:
> ...
>
> This is because the parent process doesn't pass the --depth= flag to the
> fetcher subprocess.
> ...
>
> Fix this by passing it when specified or implied by --unshallow. After
> fixing, both flags would work on shallow trees in conjunction with
> --all, as demonstrated below:
The above observes that "--depth=" given to the outer "fetch --all"
is not propagated down to subfetches.
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index b2decc6cfdb8ae86b8b1e92caa85f4961ffc47ff..a110a2dcf09c7e6764eb232bff73286753b27009 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -2247,6 +2247,8 @@ static void add_options_to_argv(struct strvec *argv,
This function is used to prepare a command line to run a single
fetch in a subprocess for 'fetch --all', and also to fetch
submodules when '--recurse-submodules' is in effect. Does the
latter case share the same problem that '--depth=<N>' is not
propagated down? Should the depth of submodules be controlled
independently by not passing '--depth=<N>' down in the first place,
in which case, this patch may be a regression for users who depend
on the behavior?
> strvec_push(argv, "--tags");
> else if (tags == TAGS_UNSET)
> strvec_push(argv, "--no-tags");
> + if (deepen)
> + strvec_pushf(argv, "--depth=%s", depth);
The 'deepen' variable checked here is set to true when any of
the '--depth=<N>', '--deepen-since=<TIME>', or
'--shallow-exclude=<REF>' were used. If the outer
'fetch --all' was told to deepen with '--deepen-since=<TIME>',
without using '--depth=<N>', what do we have in the variable
'depth' at this point? NULL?
In other words, shouldn't this be written in a more obvious,
simple, and straightforward way as three separate additions,
e.g.,
if (depth)
strvec_pushf(argv, "--depth=%s", depth);
if (deepen_since)
strvec_pushf(argv, "--shallow-since=%s", deepen_since);
if (deepen_not.nr) {
struct string_list_item *it;
for_each_string_list_item(it, &deepen_not) {
strvec_pushf(argv, "--shallow-since=%s", it->string);
}
}
Propagating 'shallow-exclude' would probably not be a good
idea if this helper function is called within the context of
recursing into submodules, as their history and refs have no
connection to the history of the top-level project. Please do
not blindly copy and paste the above to an updated patch.
prev parent reply other threads:[~2026-10-15 20:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 14:44 [PATCH] fetch: fix --depth= and --unshallow for multi-remote fetches Rong Bao
2026-10-15 20:03 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1p9qn33f.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=baorong2005@126.com \
--cc=dev@tb6.eu \
--cc=git@vger.kernel.org \
--cc=jeffbai@aosc.io \
--cc=rong.bao@csmantle.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.