From: Glen Choo <chooglen@google.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>,
Glen Choo via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Cc: Huang Zou <huang.zou@schrodinger.com>,
Josh Steadmon <steadmon@google.com>
Subject: Re: [PATCH] pull: only pass '--recurse-submodules' to subcommands
Date: Tue, 10 May 2022 11:27:21 -0700 [thread overview]
Message-ID: <kl6l35hh8cqe.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <3234941c-5190-819f-fe3a-f528942c6b44@gmail.com>
Thanks Philippe and Junio, both!
Philippe Blain <levraiphilippeblain@gmail.com> writes:
>> if (cleanup_arg)
>> /*
>> * this only checks the validity of cleanup_arg; we don't need
>> diff --git a/t/t5572-pull-submodule.sh b/t/t5572-pull-submodule.sh
>> index fa6b4cca65c..65aaa7927fb 100755
>> --- a/t/t5572-pull-submodule.sh
>> +++ b/t/t5572-pull-submodule.sh
>> @@ -107,6 +107,20 @@ test_expect_success " --[no-]recurse-submodule and submodule.recurse" '
>> test_path_is_file super/sub/merge_strategy_4.t
>> '
>>
>> +test_expect_success "fetch.recurseSubmodules option triggers recursive fetch (but not recursive update)" '
>> + test_commit -C child merge_strategy_5 &&
>> + git -C parent submodule update --remote &&
>> + git -C parent add sub &&
>> + git -C parent commit -m "update submodule" &&
>> +
>> + git -C super -c fetch.recursesubmodules=true pull --no-rebase &&
>> + # Check that the submodule commit was fetched
>> + sub_oid=$(git -C super rev-parse FETCH_HEAD:sub) &&
>> + git -C super/sub cat-file -e $sub_oid &&
>> + # Check that the submodule worktree did not update
>> + ! test_path_is_file super/sub/merge_strategy_5.t
>> +'
>> +
>
> OK so here we test the following situation:
>
> fetch.recurseSubmodules submodule.recurse --recurse-submodules fetch result pull result
> ----------------------- ----------------- -------------------- ------------ ------------
> true unset absent recursive not recursive
>
> I think this is a good start, but since the default behaviour
> of Git is the following:
>
> fetch.recurseSubmodules submodule.recurse --recurse-submodules fetch result pull result
> ----------------------- ----------------- -------------------- ------------ ------------
> default: on-demand default: false unset on-demand not recursive
>
> we end up testing something not very far from the default behaviour.
Yes, I made a silly mistake with the test.. (I could've
sworn it made sense at the time).
- fetch.recurseSubmodules=true always worked correctly when
submodule.recurse is not set because "git pull" realizes that the
behavior is unspecified, so "git fetch" doesn't receive a
"--recurse-submodules" and does the right thing.
For completeness, we probably still want this test (even though it has
always passed).
- I didn't test the actual buggy behavior, which is the precedence of
the two config values.
This would be a new test that tests something like
fetch.recurseSubmodules=foo and submodule.recurse=bar. This should be
enough to test precedence; I don't think we need to test more
combinations of values.
I hope you both didn't waste too much time on this :)
next prev parent reply other threads:[~2022-05-10 18:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-09 23:27 [PATCH] pull: only pass '--recurse-submodules' to subcommands Glen Choo via GitGitGadget
2022-05-10 0:09 ` Junio C Hamano
2022-05-10 0:44 ` Junio C Hamano
2022-05-10 13:28 ` Philippe Blain
2022-05-10 18:27 ` Glen Choo [this message]
2022-05-10 18:43 ` Glen Choo
2022-05-10 19:25 ` [PATCH v2] " Glen Choo via GitGitGadget
2022-05-11 22:30 ` Philippe Blain
2022-05-11 22:34 ` Junio C Hamano
2022-05-11 22:35 ` Philippe Blain
2022-05-11 23:21 ` Glen Choo
2022-05-12 20:37 ` Junio C Hamano
2022-05-11 23:42 ` [PATCH v3] pull: do not let submodule.recurse override fetch.recurseSubmodules Glen Choo via GitGitGadget
2022-05-12 20:38 ` Junio C Hamano
2022-05-12 23:35 ` Philippe Blain
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=kl6l35hh8cqe.fsf@chooglen-macbookpro.roam.corp.google.com \
--to=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=huang.zou@schrodinger.com \
--cc=levraiphilippeblain@gmail.com \
--cc=steadmon@google.com \
/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.