> On 17 Aug 2017, at 23:55, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > > On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider > <larsxschneider@xxxxxxxxx> wrote: >> >>> Oh, wait. >>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c >>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule' >>> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only) >>> could also be a culprit. Do you have pull.rebase set? >> >> I bisected the problem today and "a6d7eb2c7a pull: optionally rebase submodules >> (remote submodule changes only)" is indeed the culprit. >> >> The commit seems to break the following test case. >> >> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh >> index dcac364c5f..24f9729015 100755 >> --- a/t/t7400-submodule-basic.sh >> +++ b/t/t7400-submodule-basic.sh >> @@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' ' >> test_must_fail git -C multisuper_clone config --get submodule.sub1.active >> ' >> >> +test_expect_success 'submodule update and git pull with disabled submodule' ' >> + test_when_finished "rm -rf multisuper_clone" && >> + pwd=$(pwd) && >> + git clone file://"$pwd"/multisuper multisuper_clone && >> + ( >> + cd multisuper_clone && >> + git config --local submodule.sub0.update none && >> + git submodule update --init --recursive && >> + git pull --recurse-submodules && >> + git submodule status | cut -c 1,43- >actual >> + ) && >> + ls && >> + test_cmp expect multisuper_clone/actual >> +' > > Thanks for providing this test. > > cd trash directory.t7400-submodule-basic/multisuper_clone > cat .git/config > [submodule "sub0"] > update = none > active = true > url = file:///.../t/trash directory.t7400-submodule-basic/sub1 > > > submodule.<name>.update > The default update procedure for a submodule. > This variable is populated by git submodule init > from the gitmodules(5) file. See description of > update command in git-submodule(1). > > The first sentence of .update is misleading IMHO as the > these settings should strictly apply to the "submodule update" > command. So "pull --recurse-submodules" ought to ignore it, > instead the pull can do whatever it wants, namely treat the > submodule roughly like a tree and either merge/rebase > inside the submodule as well. The user *asked* for recursive > pull after all. > > Are you saying this might be a design mistake and > the .update ought to be respected by all the other > commands? For example > git reset --recurse-submodules > should ignore the .update= none? > > When designing these new recursive submodule functionality > outside the "submodule" command, I'd want submodules > to behave as much as possible like trees. In the past "submodule.<name>.update=none" was an easy way to selectively disable certain Submodules. How would I do this with Git 2.14? My gut feeling is that all commands should respect the "submodule.<name>.update=none" setting. - Lars
