{"thread":{"id":"46606","subject":"Submodule regression in 2.14?","startedAt":"2017-08-16T18:36:03Z","lastAt":"2017-08-25T16:53:43Z","messageCount":38,"participants":["Lars Schneider","Stefan Beller","Junio C Hamano","Heiko Voigt","Brandon Williams"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"326526","messageId":"4283F0B0-BC1C-4ED1-8126-7E512D84484B@gmail.com","threadId":"46606","inReplyTo":null,"subject":"Submodule regression in 2.14?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-16T18:35:56Z","receivedAt":"2017-08-16T18:36:03Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Hi,\n\nI think we discovered a regression in Git 2.14.1 today.\nIt looks like as if \"git submodule update --init --recursive\" removes\nthe \"skip submodules\" config.\n\nConsider the following steps:\n\n git clone https://server/repo.git\n cd repo\n git config --local submodule.some/other/repo.update none\n git submodule update --init --recursive\n git pull --recurse-submodules\n\nWith Git 2.14 the last \"git pull\" will clone the \"some/other/repo\"\nsubmodule. This did not happen with Git 2.13.\n\nBug or feature? I don't have anymore time for Git today. I am happy to\nprovide a proper test case tomorrow, though.\n\nCheers,\nLars\n"},{"id":"326528","messageId":"CAGZ79kajWhEOtqZLrYSAVhM_ZLDiQd9DP9GeL+J=tqach5V65A@mail.gmail.com","threadId":"46606","inReplyTo":"4283F0B0-BC1C-4ED1-8126-7E512D84484B@gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-16T18:51:30Z","receivedAt":"2017-08-16T18:51:36Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 16, 2017 at 11:35 AM, Lars Schneider\n wrote:\n> Hi,\n>\n> I think we discovered a regression in Git 2.14.1 today.\n> It looks like as if \"git submodule update --init --recursive\" removes\n> the \"skip submodules\" config.\n>\n> Consider the following steps:\n>\n> git clone https://server/repo.git\n> cd repo\n> git config --local submodule.some/other/repo.update none\n> git submodule update --init --recursive\n> git pull --recurse-submodules\n>\n> With Git 2.14 the last \"git pull\" will clone the \"some/other/repo\"\n> submodule. This did not happen with Git 2.13.\n>\n> Bug or feature? I don't have anymore time for Git today. I am happy to\n> provide a proper test case tomorrow, though.\n\n$ git log --oneline v2.13.0..v2.14.1 -- git-submodule.sh\n532139940c add: warn when adding an embedded repository\n(I am confident this is not the suspect, let's keep searching.\nNot a lot happened in submodule land apparently)\n\nLooking through all commits v2.13..v2.14 doesn't have me\nsuspect any of them.\n\nAny chance the \"did not happen with 2.13\" was not\nfreshly cloned but tested on an existing repo? If so a hot\ncandidate for suspicion is a93dcb0a56 (Merge branch\n'bw/submodule-is-active', 2017-03-30), IMHO, just\ngut feeling, though.\n\nOh, wait.\n$ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c\nc9c63ee558 Merge branch 'sb/pull-rebase-submodule'\na6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)\ncould also be a culprit. Do you have pull.rebase set?\n\n>\n> Cheers,\n> Lars\n"},{"id":"326529","messageId":"CAGZ79kadSk46v_a1JBr5Rr=Gikfbp95rPXSWaj=gk6_ZKF_HFw@mail.gmail.com","threadId":"46606","inReplyTo":"CAGZ79kajWhEOtqZLrYSAVhM_ZLDiQd9DP9GeL+J=tqach5V65A@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-16T18:53:51Z","receivedAt":"2017-08-16T18:53:58Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 16, 2017 at 11:51 AM, Stefan Beller wrote:\n\n> Any chance the \"did not happen with 2.13\" was not\n> freshly cloned but tested on an existing repo? If so a hot\n> candidate for suspicion is a93dcb0a56 (Merge branch\n> 'bw/submodule-is-active', 2017-03-30), IMHO, just\n> gut feeling, though.\n\nwhich makes it a feature, I should add.\n"},{"id":"326644","messageId":"FCB6097F-9F8D-4FDD-A8CE-D936C9CE62E7@gmail.com","threadId":"46606","inReplyTo":"CAGZ79kajWhEOtqZLrYSAVhM_ZLDiQd9DP9GeL+J=tqach5V65A@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-17T21:21:56Z","receivedAt":"2017-08-17T21:22:04Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 16 Aug 2017, at 20:51, Stefan Beller wrote:\n> \n> On Wed, Aug 16, 2017 at 11:35 AM, Lars Schneider\n> wrote:\n>> Hi,\n>> \n>> I think we discovered a regression in Git 2.14.1 today.\n>> It looks like as if \"git submodule update --init --recursive\" removes\n>> the \"skip submodules\" config.\n>> \n>> Consider the following steps:\n>> \n>> git clone https://server/repo.git\n>> cd repo\n>> git config --local submodule.some/other/repo.update none\n>> git submodule update --init --recursive\n>> git pull --recurse-submodules\n>> \n>> With Git 2.14 the last \"git pull\" will clone the \"some/other/repo\"\n>> submodule. This did not happen with Git 2.13.\n>> \n>> Bug or feature? I don't have anymore time for Git today. I am happy to\n>> provide a proper test case tomorrow, though.\n> \n> $ git log --oneline v2.13.0..v2.14.1 -- git-submodule.sh\n> 532139940c add: warn when adding an embedded repository\n> (I am confident this is not the suspect, let's keep searching.\n> Not a lot happened in submodule land apparently)\n> \n> Looking through all commits v2.13..v2.14 doesn't have me\n> suspect any of them.\n> \n> Any chance the \"did not happen with 2.13\" was not\n> freshly cloned but tested on an existing repo? If so a hot\n> candidate for suspicion is a93dcb0a56 (Merge branch\n> 'bw/submodule-is-active', 2017-03-30), IMHO, just\n> gut feeling, though.\n> \n> Oh, wait.\n> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c\n> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'\n> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)\n> could also be a culprit. Do you have pull.rebase set?\n\nI bisected the problem today and \"a6d7eb2c7a pull: optionally rebase submodules \n(remote submodule changes only)\" is indeed the culprit.\n\nThe commit seems to break the following test case.\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex dcac364c5f..24f9729015 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' '\n \ttest_must_fail git -C multisuper_clone config --get submodule.sub1.active\n '\n \n+test_expect_success 'submodule update and git pull with disabled submodule' '\n+\ttest_when_finished \"rm -rf multisuper_clone\" &&\n+\tpwd=$(pwd) &&\n+\tgit clone file://\"$pwd\"/multisuper multisuper_clone &&\n+\t(\n+\t\tcd multisuper_clone &&\n+\t\tgit config --local submodule.sub0.update none &&\n+\t\tgit submodule update --init --recursive &&\n+\t\tgit pull --recurse-submodules &&\n+\t\tgit submodule status | cut -c 1,43- >actual\n+\t) &&\n+\tls &&\n+\ttest_cmp expect multisuper_clone/actual\n+'\n+\n test_done\n\n\nI am not familiar with the code. Does anyone see the problem\nright away?\n\nThanks,\nLars\n\n\n"},{"id":"326656","messageId":"CAGZ79kb-ReME6qbDy-Q12-d=B=f6odUW_D1bAmegP4AY2AyntQ@mail.gmail.com","threadId":"46606","inReplyTo":"FCB6097F-9F8D-4FDD-A8CE-D936C9CE62E7@gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-17T21:55:27Z","receivedAt":"2017-08-17T21:55:33Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider\n wrote:\n>\n>> Oh, wait.\n>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c\n>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'\n>> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)\n>> could also be a culprit. Do you have pull.rebase set?\n>\n> I bisected the problem today and \"a6d7eb2c7a pull: optionally rebase submodules\n> (remote submodule changes only)\" is indeed the culprit.\n>\n> The commit seems to break the following test case.\n>\n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index dcac364c5f..24f9729015 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' '\n> test_must_fail git -C multisuper_clone config --get submodule.sub1.active\n> '\n>\n> +test_expect_success 'submodule update and git pull with disabled submodule' '\n> + test_when_finished \"rm -rf multisuper_clone\" &&\n> + pwd=$(pwd) &&\n> + git clone file://\"$pwd\"/multisuper multisuper_clone &&\n> + (\n> + cd multisuper_clone &&\n> + git config --local submodule.sub0.update none &&\n> + git submodule update --init --recursive &&\n> + git pull --recurse-submodules &&\n> + git submodule status | cut -c 1,43- >actual\n> + ) &&\n> + ls &&\n> + test_cmp expect multisuper_clone/actual\n> +'\n\nThanks for providing this test.\n\ncd trash directory.t7400-submodule-basic/multisuper_clone\ncat .git/config\n[submodule \"sub0\"]\n update = none\n active = true\n url = file:///.../t/trash directory.t7400-submodule-basic/sub1\n\n\nsubmodule..update\n The default update procedure for a submodule.\n This variable is populated by git submodule init\n from the gitmodules(5) file. See description of\n update command in git-submodule(1).\n\nThe first sentence of .update is misleading IMHO as the\nthese settings should strictly apply to the \"submodule update\"\ncommand. So \"pull --recurse-submodules\" ought to ignore it,\ninstead the pull can do whatever it wants, namely treat the\nsubmodule roughly like a tree and either merge/rebase\ninside the submodule as well. The user *asked* for recursive\npull after all.\n\nAre you saying this might be a design mistake and\nthe .update ought to be respected by all the other\ncommands? For example\n git reset --recurse-submodules\nshould ignore the .update= none?\n\nWhen designing these new recursive submodule functionality\noutside the \"submodule\" command, I'd want submodules\nto behave as much as possible like trees.\n\nideas?\n\nThanks,\nStefan\n\n> +\n> test_done\n>\n>\n> I am not familiar with the code. Does anyone see the problem\n> right away?\n>\n> Thanks,\n> Lars\n>\n>\n"},{"id":"326666","messageId":"xmqqd17tei7m.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kb-ReME6qbDy-Q12-d=B=f6odUW_D1bAmegP4AY2AyntQ@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-18T02:13:33Z","receivedAt":"2017-08-18T02:13:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> Are you saying this might be a design mistake and\n> the .update ought to be respected by all the other\n> commands? For example\n> git reset --recurse-submodules\n> should ignore the .update= none?\n\nI have been under the impression that that has been the traditional\ndesire of what .update ought to mean. I personally do not have a\nstrong opinion---at least not yet.\n\n> When designing these new recursive submodule functionality\n> outside the \"submodule\" command, I'd want submodules\n> to behave as much as possible like trees.\n\nI think that is sensible as long as the user does not explicitly say\n\"this and that submodule behave differently\" by giving configuration\nvariables. Perhaps .update is one of those that should countermand\nthe default behaviour of \"--recurse-submodules\"?\n"},{"id":"326671","messageId":"CAGZ79kZdnJ+bATTxKBhsJnKaJWGqcBu3MOQ9eK7m4j3dJPNbTw@mail.gmail.com","threadId":"46606","inReplyTo":"xmqqd17tei7m.fsf@gitster.mtv.corp.google.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T04:02:15Z","receivedAt":"2017-08-18T04:02:21Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> Are you saying this might be a design mistake and\n>> the .update ought to be respected by all the other\n>> commands? For example\n>> git reset --recurse-submodules\n>> should ignore the .update= none?\n>\n> I have been under the impression that that has been the traditional\n> desire of what .update ought to mean. I personally do not have a\n> strong opinion---at least not yet.\n\nIn this context note v2.14.0-rc1-34-g7463e2ec3\n(bw/submodule-config-cleanup~7, \"unpack-trees:\ndon't respect submodule.update\") that is going opposite of\nyour impression.\n\n>> When designing these new recursive submodule functionality\n>> outside the \"submodule\" command, I'd want submodules\n>> to behave as much as possible like trees.\n>\n> I think that is sensible as long as the user does not explicitly say\n> \"this and that submodule behave differently\" by giving configuration\n> variables. Perhaps .update is one of those that should countermand\n> the default behaviour of \"--recurse-submodules\"?\n\nMaybe, I'll think about it. However there is no such\nequivalent for trees (and AFAICT never came up) to\ntreat a specific directory other than the rest in worktree\noperations.\n\nThe problem with the issue in question is however:\ngit-pull is a combination of two other high level commands\n(fetch/merge), the fetch component already had\na recursive behavior, and that commit in question\nadded a bit for the merge component, so the UX\nis hard to get right for both of them:\n\n git pull --recurse=fetch-only\n git pull --recurse=merge-respects-update-strategy\n\nis what I'd want to avoid.\n\nSo maybe we can just respect the update strategy\nbefore starting the local part.\n\nStefan\n"},{"id":"326689","messageId":"D784E926-9FC7-4508-9632-225138679CDF@gmail.com","threadId":"46606","inReplyTo":"CAGZ79kb-ReME6qbDy-Q12-d=B=f6odUW_D1bAmegP4AY2AyntQ@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-18T13:12:30Z","receivedAt":"2017-08-18T13:12:40Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 17 Aug 2017, at 23:55, Stefan Beller wrote:\n> \n> On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider\n> wrote:\n>> \n>>> Oh, wait.\n>>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c\n>>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'\n>>> a6d7eb2c7a pull: optionally rebase submodules (remote submodule changes only)\n>>> could also be a culprit. Do you have pull.rebase set?\n>> \n>> I bisected the problem today and \"a6d7eb2c7a pull: optionally rebase submodules\n>> (remote submodule changes only)\" is indeed the culprit.\n>> \n>> The commit seems to break the following test case.\n>> \n>> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n>> index dcac364c5f..24f9729015 100755\n>> --- a/t/t7400-submodule-basic.sh\n>> +++ b/t/t7400-submodule-basic.sh\n>> @@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' '\n>> test_must_fail git -C multisuper_clone config --get submodule.sub1.active\n>> '\n>> \n>> +test_expect_success 'submodule update and git pull with disabled submodule' '\n>> + test_when_finished \"rm -rf multisuper_clone\" &&\n>> + pwd=$(pwd) &&\n>> + git clone file://\"$pwd\"/multisuper multisuper_clone &&\n>> + (\n>> + cd multisuper_clone &&\n>> + git config --local submodule.sub0.update none &&\n>> + git submodule update --init --recursive &&\n>> + git pull --recurse-submodules &&\n>> + git submodule status | cut -c 1,43- >actual\n>> + ) &&\n>> + ls &&\n>> + test_cmp expect multisuper_clone/actual\n>> +'\n> \n> Thanks for providing this test.\n> \n> cd trash directory.t7400-submodule-basic/multisuper_clone\n> cat .git/config\n> [submodule \"sub0\"]\n> update = none\n> active = true\n> url = file:///.../t/trash directory.t7400-submodule-basic/sub1\n> \n> \n> submodule..update\n> The default update procedure for a submodule.\n> This variable is populated by git submodule init\n> from the gitmodules(5) file. See description of\n> update command in git-submodule(1).\n> \n> The first sentence of .update is misleading IMHO as the\n> these settings should strictly apply to the \"submodule update\"\n> command. So \"pull --recurse-submodules\" ought to ignore it,\n> instead the pull can do whatever it wants, namely treat the\n> submodule roughly like a tree and either merge/rebase\n> inside the submodule as well. The user *asked* for recursive\n> pull after all.\n> \n> Are you saying this might be a design mistake and\n> the .update ought to be respected by all the other\n> commands? For example\n> git reset --recurse-submodules\n> should ignore the .update= none?\n> \n> When designing these new recursive submodule functionality\n> outside the \"submodule\" command, I'd want submodules\n> to behave as much as possible like trees.\n\nIn the past \"submodule..update=none\" was an easy way\nto selectively disable certain Submodules.\n\nHow would I do this with Git 2.14?\n\nMy gut feeling is that all commands should respect the\n\"submodule..update=none\" setting.\n\n- Lars"},{"id":"326698","messageId":"xmqq7ey0ddlk.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kZdnJ+bATTxKBhsJnKaJWGqcBu3MOQ9eK7m4j3dJPNbTw@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-18T16:50:47Z","receivedAt":"2017-08-18T16:51:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote:\n>> Stefan Beller writes:\n>>\n>>> Are you saying this might be a design mistake and\n>>> the .update ought to be respected by all the other\n>>> commands? For example\n>>> git reset --recurse-submodules\n>>> should ignore the .update= none?\n>>\n>> I have been under the impression that that has been the traditional\n>> desire of what .update ought to mean. I personally do not have a\n>> strong opinion---at least not yet.\n>\n> In this context note v2.14.0-rc1-34-g7463e2ec3\n> (bw/submodule-config-cleanup~7, \"unpack-trees:\n> don't respect submodule.update\") that is going opposite of\n> your impression.\n\nExactly. We are in agreement that recent developments seem to go\nagainst the traditional desire and it is understandable Lars sees\nthis as a regression. I still do not have a strong opinion either\nway, if this is a regression or a progress.\n\n> Maybe, I'll think about it. However there is no such\n> equivalent for trees (and AFAICT never came up) to\n> treat a specific directory other than the rest in worktree\n> operations.\n\nI am not sure if I follow. Submodules are not trees and one of the\nreasons people may want to separate things into different modules is\nso that they can treat them differently. If submodules allow you\na richer set of operations than a tree that is part of a monolithic\nproject, is that necessarily a bad thing?\n"},{"id":"326702","messageId":"CAGZ79kaC-rtfp-AMdpkpCycgk568eU2y-JDGwdoSK_E=oUJo-w@mail.gmail.com","threadId":"46606","inReplyTo":"D784E926-9FC7-4508-9632-225138679CDF@gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T17:16:14Z","receivedAt":"2017-08-18T17:16:21Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"> In the past \"submodule..update=none\" was an easy way\n> to selectively disable certain Submodules.\n>\n> How would I do this with Git 2.14?\n\n submodule..active = false\n\n> My gut feeling is that all commands should respect the\n> \"submodule..update=none\" setting.\n\nWell my gut feeling was that the \"update\" part of the name\nreponds to the subcommand, not the generic action.\n\nFor example when you set update=none, git-status,\nrecursive git-diff still reported the submodule.\n\n>\n> - Lars\n"},{"id":"326712","messageId":"CAGZ79kap-4k7n48dvBAv2pJjNy2s_LPHS-NdfQD0A-BbWqh4aQ@mail.gmail.com","threadId":"46606","inReplyTo":"xmqq7ey0ddlk.fsf@gitster.mtv.corp.google.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T19:09:53Z","receivedAt":"2017-08-18T19:10:00Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Aug 18, 2017 at 9:50 AM, Junio C Hamano wrote:\n> I am not sure if I follow. Submodules are not trees and one of the\n> reasons people may want to separate things into different modules is\n> so that they can treat them differently. If submodules allow you\n> a richer set of operations than a tree that is part of a monolithic\n> project, is that necessarily a bad thing?\n\nIt is not a bad thing on its own, but we have to consider which\nadditional actions are useful.\n\nJonathan brought up the following very long term vision:\nEventually the everyday git commands do not treat submodules\nany special than trees, even the submodules git directory\nmay be non existent (everything is absorbed into the superproject);\nso it really feels like a monorepo.\nWhen you want to work on a submodule individually, you have to\nmake a new working tree.\n"},{"id":"326713","messageId":"xmqqpobsbsk1.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kaC-rtfp-AMdpkpCycgk568eU2y-JDGwdoSK_E=oUJo-w@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-18T19:10:38Z","receivedAt":"2017-08-18T19:10:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n>> In the past \"submodule..update=none\" was an easy way\n>> to selectively disable certain Submodules.\n>>\n>> How would I do this with Git 2.14?\n>\n> submodule..active = false\n>\n>> My gut feeling is that all commands should respect the\n>> \"submodule..update=none\" setting.\n>\n> Well my gut feeling was that the \"update\" part of the name\n> reponds to the subcommand, not the generic action.\n>\n> For example when you set update=none, git-status,\n> recursive git-diff still reported the submodule.\n\nBoth status and diff are read-only operations, so this smells like a\nbit bogus argument made by comparing apples and oranges.\n\nI think Lars is more interested in operations that actually affects\nthe state of submodules by updating them---\"submodule update\" may be\na prime example as it goes down to run fetch, pull and/or checkout.\nIt may have been the only thing that affected the state of\nsubmodules before the \"--recurse-submodules\" option was added to\ncommands that affect the state of the (super)project, but I would\nthink that it is not so wrong to expect that these state-affecting\noperations running in the \"recurse into submodules\" mode to honor\n\"do not update this submodule\" that used to be honored only by\n\"submodule update\".\n"},{"id":"326722","messageId":"20170818220431.22157-1-sbeller@google.com","threadId":"46606","inReplyTo":"xmqqpobsbsk1.fsf@gitster.mtv.corp.google.com","subject":"[PATCH] pull: respect submodule update configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T22:04:31Z","receivedAt":"2017-08-18T22:04:39Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"From: Lars Schneider \n\nDo not override the submodule configuration in the call to update\nthe submodules, but give a weaker default.\n\nReported-by: Lars Schneider \nSigned-off-by: Stefan Beller \n---\n \nPersonally I dislike this patch, but I have no better idea for the time\nbeing.\n\nThanks,\nStefan \n\n builtin/pull.c | 6 ++++--\n git-submodule.sh | 7 ++++++-\n t/t7400-submodule-basic.sh | 22 ++++++++++++++++++++++\n 3 files changed, 32 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/pull.c b/builtin/pull.c\nindex 9b86e519b1..be4f74d764 100644\n--- a/builtin/pull.c\n+++ b/builtin/pull.c\n@@ -553,7 +553,8 @@ static int rebase_submodules(void)\n \tcp.git_cmd = 1;\n \tcp.no_stdin = 1;\n \targv_array_pushl(&cp.args, \"submodule\", \"update\",\n-\t\t\t\t \"--recursive\", \"--rebase\", NULL);\n+\t\t\t\t \"--recursive\", \"--default-update\",\n+\t\t\t\t \"rebase\", NULL);\n \n \treturn run_command(&cp);\n }\n@@ -565,7 +566,8 @@ static int update_submodules(void)\n \tcp.git_cmd = 1;\n \tcp.no_stdin = 1;\n \targv_array_pushl(&cp.args, \"submodule\", \"update\",\n-\t\t\t\t \"--recursive\", \"--checkout\", NULL);\n+\t\t\t\t \"--recursive\", \"--default-update\",\n+\t\t\t\t \"checkout\", NULL);\n \n \treturn run_command(&cp);\n }\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex e131760eec..6dbc32e686 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -511,6 +511,7 @@ fetch_in_submodule () (\n cmd_update()\n {\n \t# parse $args after \"submodule ... update\".\n+\tdefault_update=\"checkout\"\n \twhile test $# -ne 0\n \tdo\n \t\tcase \"$1\" in\n@@ -552,6 +553,10 @@ cmd_update()\n \t\t--checkout)\n \t\t\tupdate=\"checkout\"\n \t\t\t;;\n+\t\t--default-update)\n+\t\t\tdefault_update=\"$2\"\n+\t\t\tshift\n+\t\t\t;;\n \t\t--recommend-shallow)\n \t\t\trecommend_shallow=\"--recommend-shallow\"\n \t\t\t;;\n@@ -619,7 +624,7 @@ cmd_update()\n \t\t\tupdate_module=$(git config submodule.\"$name\".update)\n \t\t\tif test -z \"$update_module\"\n \t\t\tthen\n-\t\t\t\tupdate_module=\"checkout\"\n+\t\t\t\tupdate_module=\"$default_update\"\n \t\t\tfi\n \t\tfi\n \ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex dcac364c5f..ff64bf8528 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -1289,4 +1289,26 @@ test_expect_success 'init properly sets the config' '\n \ttest_must_fail git -C multisuper_clone config --get submodule.sub1.active\n '\n \n+test_expect_success 'submodule update and git pull with disabled submodule' '\n+\ttest_when_finished \"rm -rf multisuper_clone\" &&\n+\tpwd=$(pwd) &&\n+\tcat <<-\\EOF >expect &&\n+\t-sub0\n+\t sub1 (test2)\n+\t sub2 (test2)\n+\t sub3 (test2)\n+\t sub4 (test2)\n+\t sub5 (test2)\n+\tEOF\n+\tgit clone file://\"$pwd\"/multisuper multisuper_clone &&\n+\t(\n+\t\tcd multisuper_clone &&\n+\t\tgit config --local submodule.sub0.update none &&\n+\t\tgit submodule update --init --recursive &&\n+\t\tgit pull --recurse-submodules &&\n+\t\tgit submodule status | cut -c 1,43- >actual\n+\t) &&\n+\ttest_cmp expect multisuper_clone/actual\n+'\n+\n test_done\n-- \n2.14.0.rc0.3.g6c2e499285\n\n"},{"id":"326723","messageId":"CAGZ79kbQP8mR9Y5Yo7e4uDwQLP9NQjduuErx4YcTo=NpLCCn3A@mail.gmail.com","threadId":"46606","inReplyTo":"20170818220431.22157-1-sbeller@google.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-18T22:05:29Z","receivedAt":"2017-08-18T22:05:35Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote:\n> From: Lars Schneider \n\neh, that is what I get for amending to Lars patch.\n"},{"id":"326759","messageId":"xmqq1so8axoy.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kbQP8mR9Y5Yo7e4uDwQLP9NQjduuErx4YcTo=NpLCCn3A@mail.gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-19T06:17:17Z","receivedAt":"2017-08-19T06:17:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote:\n>> From: Lars Schneider \n>\n> eh, that is what I get for amending to Lars patch.\n\nSorry, I do not understand this remark. \n\nIf you started from a patch by Lars (I do not recall seeing it but\nthe list is high volume so it is entirely plausible that I may have\nmissed it) and tweaked it, it is more than OK to keep the original\nauthor and record it in an in-body From: header like you did,\ninstead of taking authorship over.\n\n\n"},{"id":"326760","messageId":"xmqqvalk9is0.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"20170818220431.22157-1-sbeller@google.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-19T06:24:47Z","receivedAt":"2017-08-19T06:25:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> From: Lars Schneider \n>\n> Do not override the submodule configuration in the call to update\n> the submodules, but give a weaker default.\n>\n> Reported-by: Lars Schneider \n> Signed-off-by: Stefan Beller \n> ---\n> \n> Personally I dislike this patch, but I have no better idea for the time\n> being.\n\nThe patch text from a cursory look seems reasonable to me.\n\nIt's not like you have 47 different codepaths that need to pay\nattention to the .update config and they all have to pass the new\n--default-update option, this is merely to fix one of them that\nrelates to the problem reported by Lars, and you need a similar fix\nto other 46, right?\n\nIf you want the \"--recurse-submodules\" thing to always do the\n\"weaker default\" thing in your project, you can choose not to set\n.update to custom values in any of your submodules, so I do not\nthink the reason why you dislike this change is because it would\naffect your use of submodules.\n\nSo I am a bit curious to learn which part of this change you dislike\nand why.\n\n\n> builtin/pull.c | 6 ++++--\n> git-submodule.sh | 7 ++++++-\n> t/t7400-submodule-basic.sh | 22 ++++++++++++++++++++++\n> 3 files changed, 32 insertions(+), 3 deletions(-)\n>\n> diff --git a/builtin/pull.c b/builtin/pull.c\n> index 9b86e519b1..be4f74d764 100644\n> --- a/builtin/pull.c\n> +++ b/builtin/pull.c\n> @@ -553,7 +553,8 @@ static int rebase_submodules(void)\n> \tcp.git_cmd = 1;\n> \tcp.no_stdin = 1;\n> \targv_array_pushl(&cp.args, \"submodule\", \"update\",\n> -\t\t\t\t \"--recursive\", \"--rebase\", NULL);\n> +\t\t\t\t \"--recursive\", \"--default-update\",\n> +\t\t\t\t \"rebase\", NULL);\n> \n> \treturn run_command(&cp);\n> }\n> @@ -565,7 +566,8 @@ static int update_submodules(void)\n> \tcp.git_cmd = 1;\n> \tcp.no_stdin = 1;\n> \targv_array_pushl(&cp.args, \"submodule\", \"update\",\n> -\t\t\t\t \"--recursive\", \"--checkout\", NULL);\n> +\t\t\t\t \"--recursive\", \"--default-update\",\n> +\t\t\t\t \"checkout\", NULL);\n> \n> \treturn run_command(&cp);\n> }\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index e131760eec..6dbc32e686 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -511,6 +511,7 @@ fetch_in_submodule () (\n> cmd_update()\n> {\n> \t# parse $args after \"submodule ... update\".\n> +\tdefault_update=\"checkout\"\n> \twhile test $# -ne 0\n> \tdo\n> \t\tcase \"$1\" in\n> @@ -552,6 +553,10 @@ cmd_update()\n> \t\t--checkout)\n> \t\t\tupdate=\"checkout\"\n> \t\t\t;;\n> +\t\t--default-update)\n> +\t\t\tdefault_update=\"$2\"\n> +\t\t\tshift\n> +\t\t\t;;\n> \t\t--recommend-shallow)\n> \t\t\trecommend_shallow=\"--recommend-shallow\"\n> \t\t\t;;\n> @@ -619,7 +624,7 @@ cmd_update()\n> \t\t\tupdate_module=$(git config submodule.\"$name\".update)\n> \t\t\tif test -z \"$update_module\"\n> \t\t\tthen\n> -\t\t\t\tupdate_module=\"checkout\"\n> +\t\t\t\tupdate_module=\"$default_update\"\n> \t\t\tfi\n> \t\tfi\n> \n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index dcac364c5f..ff64bf8528 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -1289,4 +1289,26 @@ test_expect_success 'init properly sets the config' '\n> \ttest_must_fail git -C multisuper_clone config --get submodule.sub1.active\n> '\n> \n> +test_expect_success 'submodule update and git pull with disabled submodule' '\n> +\ttest_when_finished \"rm -rf multisuper_clone\" &&\n> +\tpwd=$(pwd) &&\n> +\tcat <<-\\EOF >expect &&\n> +\t-sub0\n> +\t sub1 (test2)\n> +\t sub2 (test2)\n> +\t sub3 (test2)\n> +\t sub4 (test2)\n> +\t sub5 (test2)\n> +\tEOF\n> +\tgit clone file://\"$pwd\"/multisuper multisuper_clone &&\n> +\t(\n> +\t\tcd multisuper_clone &&\n> +\t\tgit config --local submodule.sub0.update none &&\n> +\t\tgit submodule update --init --recursive &&\n> +\t\tgit pull --recurse-submodules &&\n> +\t\tgit submodule status | cut -c 1,43- >actual\n> +\t) &&\n> +\ttest_cmp expect multisuper_clone/actual\n> +'\n> +\n> test_done\n"},{"id":"326761","messageId":"xmqqpobs9hjy.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kap-4k7n48dvBAv2pJjNy2s_LPHS-NdfQD0A-BbWqh4aQ@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-19T06:51:13Z","receivedAt":"2017-08-19T06:51:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> Jonathan brought up the following very long term vision:\n> Eventually the everyday git commands do not treat submodules\n> any special than trees, even the submodules git directory\n> may be non existent (everything is absorbed into the superproject);\n> so it really feels like a monorepo.\n\nThat may be one valid option to have but I do not see a reason why\nit needs to be the only valid option. So I do not see why you are\nbringing it up in this thread.\n\nBut that is a good starting point to discuss one possible future.\nLet's think aloud how that world would look like.\n\n * When you \"git clone\" a superproject (perhaps implicitly with the\n \"--recurse-submodules\" option), the top-level project and all of\n its submodules will be checked out on the same branch (presumably\n the 'master' branch, which is the default).\n\n * Your attempt to \"git commit\", \"git branch\", \"git checkout -b\",\n etc. inside a submodule will either fail, or will implicitly\n chdir up to the top-level superproject and turn into the\n corresponding command with \"--recurse-submodules\".\n\n * \"git commit --recurse-submodules -a\" from the top-level will grab\n all the local changes, depth-first and recursively, in\n submodules, makes a commit, binds the new commit to the index of\n the superproject that immediately contains the submodule and\n makes a commit in it, until it percolates all the way up to the\n superproject. When working in this mode, branches in submodules\n do not really matter; the gitlink in the superproject is the only\n thing that matters.\n\n * It naturally follows that between two adjacent commits C and C~1\n in the superproject's history, the commit in a submodule bound to\n C and the commit in a submodule bound to C~1 are either the same\n (i.e. superproject made a commit but there was no change in the\n submodule), or they are in direct parent-child relationship\n (i.e. the local changes made to the submodule was recorded as a\n single commit when the superproject made the commit).\n\n * \"git push --recurse-submodules\" from the top-level will push the\n history of the superproject out, together with the history of the\n submodules.\n\nI think it is doable, but a mechanism to enumerate all the commits\nbound from submodules to a range of superproject's commits needs to\nbe invented to drive the pack-objects for efficient object transfer.\nHaving it would also help in fsck and gc---as branches are immaterial\nin the submodule repositories, commits in superprojects that are\nreachable from refs will have to serve as the connectivity anchors\nfor commit DAG in the submodule histories.\n\nAs long as we are talking about idealized future world (well, at\nleast an idea of somebody's \"ideal\", not necessarily shared by\neverybody), I wonder if there is even any need to have commits in\nsubmodules in such a world. To realize such a \"monorepo\" world, you\nmight be better off allowing a gitlink in the superproject to\ndirectly point at a tree object in a submodule repository (making\nthem physically a single repository is an optional implementation\ndetail I choose to ignore in this discussion).\n"},{"id":"326781","messageId":"89AB8AA3-8E19-46BA-B169-D1EA4CF4ABE7@gmail.com","threadId":"46606","inReplyTo":"CAGZ79kaC-rtfp-AMdpkpCycgk568eU2y-JDGwdoSK_E=oUJo-w@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-19T18:24:20Z","receivedAt":"2017-08-19T18:24:28Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 18 Aug 2017, at 19:16, Stefan Beller wrote:\n> \n>> In the past \"submodule..update=none\" was an easy way\n>> to selectively disable certain Submodules.\n>> \n>> How would I do this with Git 2.14?\n> \n> submodule..active = false\n\nThat's what I thought after your first response. However,\nthis test case fails for me, too:\n\n\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex dcac364c5f..24f9729015 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -1289,4 +1289,19 @@ test_expect_success 'init properly sets the config' '\n\ttest_must_fail git -C multisuper_clone config --get submodule.sub1.active\n'\n\n+test_expect_success 'submodule update and git pull with disabled submodule' '\n+\ttest_when_finished \"rm -rf multisuper_clone\" &&\n+\tpwd=$(pwd) &&\n+\tgit clone file://\"$pwd\"/multisuper multisuper_clone &&\n+\t(\n+\t\tcd multisuper_clone &&\n+\t\tgit config --local submodule.sub0.update none &&\n+\t\tgit config --local submodule.sub0.active false &&\n+\t\tgit submodule update --init --recursive &&\n+\t\tgit pull --recurse-submodules &&\n+\t\tgit submodule status | cut -c 1,43- >actual\n+\t) &&\n+\tls &&\n+\ttest_cmp expect multisuper_clone/actual\n+'\n+\ntest_done\n\n\nHere is the relevant part of the Git config:\n\n\t[submodule \"sub0\"]\n\t\tupdate = none\n\t\tactive = false\n\nIs this a bug?\n\n\n>> My gut feeling is that all commands should respect the\n>> \"submodule..update=none\" setting.\n> \n> Well my gut feeling was that the \"update\" part of the name\n> reponds to the subcommand, not the generic action.\n\nI see. But wouldn't that be inconsistent with the config\n\"active\" then? Following that logic \"active\" would only\nrespond to the (non-existent) \"active\" subcommand, no?\n\n\n> For example when you set update=none, git-status,\n> recursive git-diff still reported the submodule.\n\nMy understanding is this:\n\n(1) \"active\" controls if a submodule is considered by\n Git at all.\n\n(2) \"update\" controls how and if the submodule pointer\n modified\n\nIs this your intention? What would be the use case for\n\"active=true\" and \"update=none\"? \n\n\n- Lars"},{"id":"326881","messageId":"20170821160514.GA1618@book.hvoigt.net","threadId":"46606","inReplyTo":"xmqqpobs9hjy.fsf@gitster.mtv.corp.google.com","subject":"Re: Submodule regression in 2.14?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-21T16:05:14Z","receivedAt":"2017-08-21T16:05:28Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n> As long as we are talking about idealized future world (well, at\n> least an idea of somebody's \"ideal\", not necessarily shared by\n> everybody), I wonder if there is even any need to have commits in\n> submodules in such a world. To realize such a \"monorepo\" world, you\n> might be better off allowing a gitlink in the superproject to\n> directly point at a tree object in a submodule repository (making\n> them physically a single repository is an optional implementation\n> detail I choose to ignore in this discussion).\n\nIMO this is one step to far. One main use of submodules are shared\nrepositories that are used by many superprojects. The reason you want to\nhave commits in the submodule are so that you can push them\nindependently and all other users can pick up the changes. You could get\nby by Using the superproject commits for the submodule once you push or\nsomething but those do not necessarily make sense in the context of the\nsubmodule.\n\nSo I think it is important that there are commits in the submodule so\nits history makes sense independently for others.\n\nOr how would you push out the history in the submodule in your idea?\nMaybe I am missing something? What would be your use case with gitlinks\npointing to trees?\n\nCheers Heiko\n"},{"id":"326882","messageId":"20170821162056.GB1618@book.hvoigt.net","threadId":"46606","inReplyTo":"xmqqvalk9is0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-21T16:20:56Z","receivedAt":"2017-08-21T16:21:09Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Fri, Aug 18, 2017 at 11:24:47PM -0700, Junio C Hamano wrote:\n> Stefan Beller writes:\n> \n> > From: Lars Schneider \n> >\n> > Do not override the submodule configuration in the call to update\n> > the submodules, but give a weaker default.\n> >\n> > Reported-by: Lars Schneider \n> > Signed-off-by: Stefan Beller \n> > ---\n> > \n> > Personally I dislike this patch, but I have no better idea for the time\n> > being.\n> \n> The patch text from a cursory look seems reasonable to me.\n> \n> It's not like you have 47 different codepaths that need to pay\n> attention to the .update config and they all have to pass the new\n> --default-update option, this is merely to fix one of them that\n> relates to the problem reported by Lars, and you need a similar fix\n> to other 46, right?\n> \n> If you want the \"--recurse-submodules\" thing to always do the\n> \"weaker default\" thing in your project, you can choose not to set\n> .update to custom values in any of your submodules, so I do not\n> think the reason why you dislike this change is because it would\n> affect your use of submodules.\n> \n> So I am a bit curious to learn which part of this change you dislike\n> and why.\n\nI am also curious. Isn't this the same strategy we are using in other\nplaces?\n\nCheers Heiko\n"},{"id":"326883","messageId":"CAGZ79kZvcY8hawq1qGfFLm1Ukb-wn8j0e_hN8gF5jrEY20o7YA@mail.gmail.com","threadId":"46606","inReplyTo":"20170821160514.GA1618@book.hvoigt.net","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-21T16:42:54Z","receivedAt":"2017-08-21T16:43:00Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n> On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n>> As long as we are talking about idealized future world (well, at\n>> least an idea of somebody's \"ideal\", not necessarily shared by\n>> everybody), I wonder if there is even any need to have commits in\n>> submodules in such a world. To realize such a \"monorepo\" world, you\n>> might be better off allowing a gitlink in the superproject to\n>> directly point at a tree object in a submodule repository (making\n>> them physically a single repository is an optional implementation\n>> detail I choose to ignore in this discussion).\n>\n> IMO this is one step to far. One main use of submodules are shared\n> repositories that are used by many superprojects. The reason you want to\n> have commits in the submodule are so that you can push them\n> independently and all other users can pick up the changes. You could get\n> by by Using the superproject commits for the submodule once you push or\n> something but those do not necessarily make sense in the context of the\n> submodule.\n>\n> So I think it is important that there are commits in the submodule so\n> its history makes sense independently for others.\n>\n> Or how would you push out the history in the submodule in your idea?\n> Maybe I am missing something? What would be your use case with gitlinks\n> pointing to trees?\n\nWell there are still commits, but in the superproject the UX feels more\nas if the submodules were special trees. So if you want to interact with\nthe submodule specifically, you could do things like\n\n git add /path/inside/sub\n # works seamlessly from the superproject tree\n\n git commit --submodule-commit-only\n # When the flag is not give, you may get an editor\n # asking for two commit messages, (sub+super)\n\n git fetch --submodule\n # When the flag is not given, we'd fetch superproject and\n # on-demand\n\n # You feel the superproject is in the way?\n git worktree add --for-submodule ...\n # The new submodule worktree puts the\n # submodule only UX first. so it feels like its own\n # repository, no need for specific flags.\n\n\n>\n> Cheers Heiko\n"},{"id":"326885","messageId":"CAGZ79kYaBGDyScWihJ7gRdbiJfMPOnNo8LfkB58+WAcOtXyibQ@mail.gmail.com","threadId":"46606","inReplyTo":"xmqqpobs9hjy.fsf@gitster.mtv.corp.google.com","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-21T16:46:23Z","receivedAt":"2017-08-21T16:46:29Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:\n\n> As long as we are talking about idealized future world (well, at\n> least an idea of somebody's \"ideal\", not necessarily shared by\n> everybody), I wonder if there is even any need to have commits in\n> submodules in such a world. To realize such a \"monorepo\" world, you\n> might be better off allowing a gitlink in the superproject to\n> directly point at a tree object in a submodule repository (making\n> them physically a single repository is an optional implementation\n> detail I choose to ignore in this discussion).\n\nThen the sharing between superprojects (e.g. send an Android's linux\npatch upstream or to another distro that also uses a superproject),\nbecomes cumbersome as the commit messages are missing and\npotentially not specific to that subtree.\n"},{"id":"326887","messageId":"xmqqr2w46f4c.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"20170821160514.GA1618@book.hvoigt.net","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-21T16:48:51Z","receivedAt":"2017-08-21T16:49:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> So I think it is important that there are commits in the submodule so\n> its history makes sense independently for others.\n\nI was trying to push the \"just like trees\" to the logical conclusion\nin order to see see if it leads to an absurd conclusions, or some\nuseful scenario. I do not necessarily subscribed to Jonathan's\n\"vision\" (I do not object to it as one possible mode of operation,\neither).\n\n> Or how would you push out the history in the submodule in your idea?\n> Maybe I am missing something? What would be your use case with gitlinks\n> pointing to trees?\n\nNot my idea. But Stefan's message I was responding to said that\nobject database for the superproject is the same as and mixed with\nobject databases for the submodules, so it is plausible that push\nalways happens at the superproject, and a mechanism to be invented\n(I mentioned the need for it in the message you are responding to)\nto enumerate all the commits bound from submodules to a range of\nsuperproject's commits would identify these trees to be pushed out.\n\nIn essense, \"just like trees\" folks want to use the gitlinks in the\nsuperproject to only specify the tree from the submodule project\nthat should sit there. And my point is that such a world view would\nlead to no need for branches in the submodule repository, no need\nfor commits in the submodule repository, and no need for history in\nthe submodule repository. Which may or may not be a bad thing.\n"},{"id":"326888","messageId":"CAGZ79ka1jyxmATQbrjPHAv3227UJNcN0nw9AY-RZXnNahepoGQ@mail.gmail.com","threadId":"46606","inReplyTo":"20170821162056.GB1618@book.hvoigt.net","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-21T16:55:14Z","receivedAt":"2017-08-21T16:55:23Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:\n\n>> So I am a bit curious to learn which part of this change you dislike\n>> and why.\n>\n> I am also curious. Isn't this the same strategy we are using in other\n> places?\n>\n\nI dislike it because the UX feels crude. When reading the documentation,\nit seems to me as if submodule. can be one of the following\n\n (none, checkout, rebase, merge, !)\n\nThis is perfect for \"submodule-update\", whose primary goal is\nto update submodules *somehow*. However other commands\n\n git rebase --recurse\n git merge --recurse\n git checkout --recurse\n\nhave a different primary mode of operation (note how their name\nis one of the modes from the set above), so it may get confusing\nfor a user.\n\n'none' and '!' seem like they would be okay\nfor any of the commands above but then:\n\n git config submodule..update \"!...\"\n git reset --hard --recurse\n git status\n # submodule is reported, because \"!...\" did not 'reset'.\n\nAnyway. That dislike is just a minor gut feeling about the UX/UI\nbeing horrible. I wrote the patch to keep the conversation going,\nand if it fixes Lars problem, let's take it for now.\n\nThanks,\nStefan\n"},{"id":"326889","messageId":"85ED93BC-1E27-4B8D-856D-090C6860BAB0@gmail.com","threadId":"46606","inReplyTo":"CAGZ79ka1jyxmATQbrjPHAv3227UJNcN0nw9AY-RZXnNahepoGQ@mail.gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-21T17:20:25Z","receivedAt":"2017-08-21T17:20:34Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 21 Aug 2017, at 18:55, Stefan Beller wrote:\n> \n> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:\n> \n>>> So I am a bit curious to learn which part of this change you dislike\n>>> and why.\n>> \n>> I am also curious. Isn't this the same strategy we are using in other\n>> places?\n>> \n> \n> I dislike it because the UX feels crude. When reading the documentation,\n> it seems to me as if submodule. can be one of the following\n> \n> (none, checkout, rebase, merge, !)\n> \n> This is perfect for \"submodule-update\", whose primary goal is\n> to update submodules *somehow*. However other commands\n> \n> git rebase --recurse\n> git merge --recurse\n> git checkout --recurse\n> \n> have a different primary mode of operation (note how their name\n> is one of the modes from the set above), so it may get confusing\n> for a user.\n> \n> 'none' and '!' seem like they would be okay\n> for any of the commands above but then:\n> \n> git config submodule..update \"!...\"\n> git reset --hard --recurse\n> git status\n> # submodule is reported, because \"!...\" did not 'reset'.\n> \n> Anyway. That dislike is just a minor gut feeling about the UX/UI\n> being horrible. I wrote the patch to keep the conversation going,\n> and if it fixes Lars problem, let's take it for now.\n\nWell, I need just a way to disable certain Submodules completely.\nIf you show me how \"git config --local submodule.sub.active false\"\nworks then I don't need this patch.\n\nI tried to make it work here:\nhttps://public-inbox.org/git/89AB8AA3-8E19-46BA-B169-D1EA4CF4ABE7@gmail.com/\n\nThanks,\nLars\n"},{"id":"326896","messageId":"CAGZ79kZMjGNOn0FnJGtO5gRY3rF0Eiow8n0uppTZsCUAHY+m3A@mail.gmail.com","threadId":"46606","inReplyTo":"85ED93BC-1E27-4B8D-856D-090C6860BAB0@gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-21T17:48:10Z","receivedAt":"2017-08-21T17:48:15Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Aug 21, 2017 at 10:20 AM, Lars Schneider\n wrote:\n>\n>> On 21 Aug 2017, at 18:55, Stefan Beller wrote:\n>>\n>> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:\n>>\n>>>> So I am a bit curious to learn which part of this change you dislike\n>>>> and why.\n>>>\n>>> I am also curious. Isn't this the same strategy we are using in other\n>>> places?\n>>>\n>>\n>> I dislike it because the UX feels crude. When reading the documentation,\n>> it seems to me as if submodule. can be one of the following\n>>\n>> (none, checkout, rebase, merge, !)\n>>\n>> This is perfect for \"submodule-update\", whose primary goal is\n>> to update submodules *somehow*. However other commands\n>>\n>> git rebase --recurse\n>> git merge --recurse\n>> git checkout --recurse\n>>\n>> have a different primary mode of operation (note how their name\n>> is one of the modes from the set above), so it may get confusing\n>> for a user.\n>>\n>> 'none' and '!' seem like they would be okay\n>> for any of the commands above but then:\n>>\n>> git config submodule..update \"!...\"\n>> git reset --hard --recurse\n>> git status\n>> # submodule is reported, because \"!...\" did not 'reset'.\n>>\n>> Anyway. That dislike is just a minor gut feeling about the UX/UI\n>> being horrible. I wrote the patch to keep the conversation going,\n>> and if it fixes Lars problem, let's take it for now.\n>\n> Well, I need just a way to disable certain Submodules completely.\n> If you show me how \"git config --local submodule.sub.active false\"\n> works then I don't need this patch.\n>\n> I tried to make it work here:\n> https://public-inbox.org/git/89AB8AA3-8E19-46BA-B169-D1EA4CF4ABE7@gmail.com/\n\n(A) you need to set expect there as well, to have sub{2,4,5} be expected\nthere as well.\n\n(B) That may hint at another (UX) bug.\n\nThe test case there uses \"git submodule update --init\".\nThe init flag will set all submodules to active.\n\nMaybe you want\n\n git config submodule.active \":(exclude)sub0\"\n git config --add submodule.active \":(exclude)sub2\"\n git config --add submodule.active \".\"\n # Read: anything except sub0 and sub2 are interesting\n\n git submodule update\n # no init flag, needed even for new submodules IIUC\n"},{"id":"326898","messageId":"20170821182110.GA156514@google.com","threadId":"46606","inReplyTo":"CAGZ79kZMjGNOn0FnJGtO5gRY3rF0Eiow8n0uppTZsCUAHY+m3A@mail.gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-08-21T18:21:10Z","receivedAt":"2017-08-21T18:21:19Z","isPatch":true,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 08/21, Stefan Beller wrote:\n> On Mon, Aug 21, 2017 at 10:20 AM, Lars Schneider\n> wrote:\n> >\n> >> On 21 Aug 2017, at 18:55, Stefan Beller wrote:\n> >>\n> >> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:\n> >>\n> >>>> So I am a bit curious to learn which part of this change you dislike\n> >>>> and why.\n> >>>\n> >>> I am also curious. Isn't this the same strategy we are using in other\n> >>> places?\n> >>>\n> >>\n> >> I dislike it because the UX feels crude. When reading the documentation,\n> >> it seems to me as if submodule. can be one of the following\n> >>\n> >> (none, checkout, rebase, merge, !)\n> >>\n> >> This is perfect for \"submodule-update\", whose primary goal is\n> >> to update submodules *somehow*. However other commands\n> >>\n> >> git rebase --recurse\n> >> git merge --recurse\n> >> git checkout --recurse\n> >>\n> >> have a different primary mode of operation (note how their name\n> >> is one of the modes from the set above), so it may get confusing\n> >> for a user.\n> >>\n> >> 'none' and '!' seem like they would be okay\n> >> for any of the commands above but then:\n> >>\n> >> git config submodule..update \"!...\"\n> >> git reset --hard --recurse\n> >> git status\n> >> # submodule is reported, because \"!...\" did not 'reset'.\n> >>\n> >> Anyway. That dislike is just a minor gut feeling about the UX/UI\n> >> being horrible. I wrote the patch to keep the conversation going,\n> >> and if it fixes Lars problem, let's take it for now.\n> >\n> > Well, I need just a way to disable certain Submodules completely.\n> > If you show me how \"git config --local submodule.sub.active false\"\n> > works then I don't need this patch.\n\nYeah if you want to completely disable a submodule (as in not even check\nit out) then setting .active to false would do that. But as stefan\npointed out and IIRC 'submodule update --init' with no pathspec sets all\nsubmodules to be active. Perhaps it should only init submodules who\ndon't already have an explicit active flag set.\n\n> >\n> > I tried to make it work here:\n> > https://public-inbox.org/git/89AB8AA3-8E19-46BA-B169-D1EA4CF4ABE7@gmail.com/\n> \n> (A) you need to set expect there as well, to have sub{2,4,5} be expected\n> there as well.\n> \n> (B) That may hint at another (UX) bug.\n> \n> The test case there uses \"git submodule update --init\".\n> The init flag will set all submodules to active.\n> \n> Maybe you want\n> \n> git config submodule.active \":(exclude)sub0\"\n> git config --add submodule.active \":(exclude)sub2\"\n> git config --add submodule.active \".\"\n> # Read: anything except sub0 and sub2 are interesting\n> \n> git submodule update\n> # no init flag, needed even for new submodules IIUC\n\n-- \nBrandon Williams\n"},{"id":"326911","messageId":"xmqqefs45yl8.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"CAGZ79kYaBGDyScWihJ7gRdbiJfMPOnNo8LfkB58+WAcOtXyibQ@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-21T22:45:55Z","receivedAt":"2017-08-21T22:46:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Fri, Aug 18, 2017 at 11:51 PM, Junio C Hamano wrote:\n>\n>> As long as we are talking about idealized future world (well, at\n>> least an idea of somebody's \"ideal\", not necessarily shared by\n>> everybody), I wonder if there is even any need to have commits in\n>> submodules in such a world. To realize such a \"monorepo\" world, you\n>> might be better off allowing a gitlink in the superproject to\n>> directly point at a tree object in a submodule repository (making\n>> them physically a single repository is an optional implementation\n>> detail I choose to ignore in this discussion).\n>\n> Then the sharing between superprojects (e.g. send an Android's linux\n> patch upstream or to another distro that also uses a superproject),\n> becomes cumbersome as the commit messages are missing and\n> potentially not specific to that subtree.\n\nIndeed. That is a problem \"git commit --recurse-submodules\" has.\nSocratic method seem to have worked well to convince you that it is\nnot necessarily a good idea to make submodules \"just like a tree\".\n\n"},{"id":"326912","messageId":"xmqqa82s5yau.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"20170821182110.GA156514@google.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-21T22:52:09Z","receivedAt":"2017-08-21T22:52:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Williams writes:\n\n>> > I tried to make it work here:\n>> > https://public-inbox.org/git/89AB8AA3-8E19-46BA-B169-D1EA4CF4ABE7@gmail.com/\n>> \n>> (A) you need to set expect there as well, to have sub{2,4,5} be expected\n>> there as well.\n>> \n>> (B) That may hint at another (UX) bug.\n>> \n>> The test case there uses \"git submodule update --init\".\n>> The init flag will set all submodules to active.\n>> \n>> Maybe you want\n>> \n>> git config submodule.active \":(exclude)sub0\"\n>> git config --add submodule.active \":(exclude)sub2\"\n>> git config --add submodule.active \".\"\n>> # Read: anything except sub0 and sub2 are interesting\n>> \n>> git submodule update\n>> # no init flag, needed even for new submodules IIUC\n\nSounds like a good solution. I do think what Stefan said about\n\"reset --hard --recurse-submodules\" makes tons of sense, and we\nshould do a hard reset in submodules as long as they are marked\nas active, regardless of what the .update option says. I have\nnot thought deeply enough about other operations like \"pull\" in\nhis message to be able to comment, though.\n\nThanks.\n"},{"id":"326929","messageId":"D44F6340-9011-4D41-B103-4A61E7248806@gmail.com","threadId":"46606","inReplyTo":"20170821182110.GA156514@google.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-22T14:50:06Z","receivedAt":"2017-08-22T14:50:14Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 21 Aug 2017, at 20:21, Brandon Williams wrote:\n> \n> On 08/21, Stefan Beller wrote:\n>> On Mon, Aug 21, 2017 at 10:20 AM, Lars Schneider\n>> wrote:\n>>> \n>>>> On 21 Aug 2017, at 18:55, Stefan Beller wrote:\n>>>> \n>>>> On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote:\n>>>> \n>>>>>> So I am a bit curious to learn which part of this change you dislike\n>>>>>> and why.\n>>>>> \n>>>>> I am also curious. Isn't this the same strategy we are using in other\n>>>>> places?\n>>>>> \n>>>> \n>>>> I dislike it because the UX feels crude. When reading the documentation,\n>>>> it seems to me as if submodule. can be one of the following\n>>>> \n>>>> (none, checkout, rebase, merge, !)\n>>>> \n>>>> This is perfect for \"submodule-update\", whose primary goal is\n>>>> to update submodules *somehow*. However other commands\n>>>> \n>>>> git rebase --recurse\n>>>> git merge --recurse\n>>>> git checkout --recurse\n>>>> \n>>>> have a different primary mode of operation (note how their name\n>>>> is one of the modes from the set above), so it may get confusing\n>>>> for a user.\n>>>> \n>>>> 'none' and '!' seem like they would be okay\n>>>> for any of the commands above but then:\n>>>> \n>>>> git config submodule..update \"!...\"\n>>>> git reset --hard --recurse\n>>>> git status\n>>>> # submodule is reported, because \"!...\" did not 'reset'.\n>>>> \n>>>> Anyway. That dislike is just a minor gut feeling about the UX/UI\n>>>> being horrible. I wrote the patch to keep the conversation going,\n>>>> and if it fixes Lars problem, let's take it for now.\n>>> \n>>> Well, I need just a way to disable certain Submodules completely.\n>>> If you show me how \"git config --local submodule.sub.active false\"\n>>> works then I don't need this patch.\n> \n> Yeah if you want to completely disable a submodule (as in not even check\n> it out) then setting .active to false would do that. But as stefan\n> pointed out and IIRC 'submodule update --init' with no pathspec sets all\n> submodules to be active. Perhaps it should only init submodules who\n> don't already have an explicit active flag set.\n\nOK. I change my scripts to use \".active\" and it seems to work nicely.\n\nI noticed one oddity, though:\n\nIf I clone a repo using `git clone --recursive ` then the local\nGit config of the repo gets the following entry:\n\n[submodule]\n\tactive = .\n\nIs this intentional? Something in the git/git test harness seems to prevent\nthat. I was not able to write a test to replicate the issue.\n\nAny idea?\n\nThanks,\nLars"},{"id":"326933","messageId":"20170822153311.GA5697@book.hvoigt.net","threadId":"46606","inReplyTo":"CAGZ79kZvcY8hawq1qGfFLm1Ukb-wn8j0e_hN8gF5jrEY20o7YA@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-22T15:33:11Z","receivedAt":"2017-08-22T15:33:22Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:\n> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n> >> As long as we are talking about idealized future world (well, at\n> >> least an idea of somebody's \"ideal\", not necessarily shared by\n> >> everybody), I wonder if there is even any need to have commits in\n> >> submodules in such a world. To realize such a \"monorepo\" world, you\n> >> might be better off allowing a gitlink in the superproject to\n> >> directly point at a tree object in a submodule repository (making\n> >> them physically a single repository is an optional implementation\n> >> detail I choose to ignore in this discussion).\n> >\n> > IMO this is one step to far. One main use of submodules are shared\n> > repositories that are used by many superprojects. The reason you want to\n> > have commits in the submodule are so that you can push them\n> > independently and all other users can pick up the changes. You could get\n> > by by Using the superproject commits for the submodule once you push or\n> > something but those do not necessarily make sense in the context of the\n> > submodule.\n> >\n> > So I think it is important that there are commits in the submodule so\n> > its history makes sense independently for others.\n> >\n> > Or how would you push out the history in the submodule in your idea?\n> > Maybe I am missing something? What would be your use case with gitlinks\n> > pointing to trees?\n> \n> Well there are still commits, but in the superproject the UX feels more\n> as if the submodules were special trees.\n\nAh ok then I misunderstood. So they only feel like trees.\n\n> So if you want to interact with\n> the submodule specifically, you could do things like\n> \n> git add /path/inside/sub\n> # works seamlessly from the superproject tree\n\nWould that mean that we need to loosen/keep the requirement loose for a\nname from .gitmodules? I am asking because of my series for on-demand\nfetch of renamed submodules. For the full functionality I would require\na name.\n\nWould that be in a scenario where the user would then e.g. push the\nsubmodule into the superproject?\n\nAh wait I misunderstood again. You mean a file in an existing\nsubmodule right? Not adding submodule from a repository a user moved\nthere?\n\n> git commit --submodule-commit-only\n> # When the flag is not give, you may get an editor\n> # asking for two commit messages, (sub+super)\n\nOr maybe something like\n\n git commit --submodule path/to/submodule\n\nso the user can specify which submodule she wants. I first wrote it\nwithout the switch but but that collides with listing files which should\nbe added. IMO this shorter option is also more intuitive to understand\nwhat it does (for this case).\n\n> git fetch --submodule\n> # When the flag is not given, we'd fetch superproject and\n> # on-demand\n\nYes like above we should add the path to the submodule right?\n\n> # You feel the superproject is in the way?\n> git worktree add --for-submodule ...\n> # The new submodule worktree puts the\n> # submodule only UX first. so it feels like its own\n> # repository, no need for specific flags.\n\nI am not sure I understand this one. What would that do? Put a worktree\nfor submodule path/to/sub to ...?\n\nOverall I like the direction of these ideas.\n\nCheers Heiko\n"},{"id":"326934","messageId":"20170822155022.GB5697@book.hvoigt.net","threadId":"46606","inReplyTo":"xmqqr2w46f4c.fsf@gitster.mtv.corp.google.com","subject":"Re: Submodule regression in 2.14?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-22T15:50:22Z","receivedAt":"2017-08-22T15:50:33Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Aug 21, 2017 at 09:48:51AM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> > So I think it is important that there are commits in the submodule so\n> > its history makes sense independently for others.\n> \n> I was trying to push the \"just like trees\" to the logical conclusion\n> in order to see see if it leads to an absurd conclusions, or some\n> useful scenario. I do not necessarily subscribed to Jonathan's\n> \"vision\" (I do not object to it as one possible mode of operation,\n> either).\n> \n> > Or how would you push out the history in the submodule in your idea?\n> > Maybe I am missing something? What would be your use case with gitlinks\n> > pointing to trees?\n> \n> Not my idea. But Stefan's message I was responding to said that\n> object database for the superproject is the same as and mixed with\n> object databases for the submodules, so it is plausible that push\n> always happens at the superproject, and a mechanism to be invented\n> (I mentioned the need for it in the message you are responding to)\n> to enumerate all the commits bound from submodules to a range of\n> superproject's commits would identify these trees to be pushed out.\n> \n> In essense, \"just like trees\" folks want to use the gitlinks in the\n> superproject to only specify the tree from the submodule project\n> that should sit there. And my point is that such a world view would\n> lead to no need for branches in the submodule repository, no need\n> for commits in the submodule repository, and no need for history in\n> the submodule repository. Which may or may not be a bad thing.\n\nThe problem I see here is: How do we seperate the submodule from the\nsuperproject? Without the history (commits and trees) of the\nsuperproject the submodule trees do not make sense anymore. The reason\nusers have submodules is because the projects are seperate somehow. With\njust trees in the submodule it becomes tied quite tightly to the\nsuperproject, IMO.\n\nOne step further: Why use gitlinks to point to trees? Let's just use\nnormal tree links instead, we already have that implemented :)\n\nCheers Heiko\n"},{"id":"326948","messageId":"CAGZ79kbpf-a_ZinPLuPh2Vq629=cQknuLVF-QVwOeae1ZGS2Cw@mail.gmail.com","threadId":"46606","inReplyTo":"D44F6340-9011-4D41-B103-4A61E7248806@gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-22T17:51:24Z","receivedAt":"2017-08-22T17:51:32Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 22, 2017 at 7:50 AM, Lars Schneider\n wrote:\n>\n> OK. I change my scripts to use \".active\" and it seems to work nicely.\n>\n> I noticed one oddity, though:\n>\n> If I clone a repo using `git clone --recursive ` then the local\n> Git config of the repo gets the following entry:\n>\n> [submodule]\n> active = .\n\nbb62e0a99f (clone: teach --recurse-submodules to optionally take a\npathspec, 2017-03-17) makes it clear that this is intentional for\n--recurse-submodules, but doesn't exactly state that --recurse will\nbehave the same. The idea here is that at clone time you can already\ngive\n\n git clone --recurse=:(exclude)sub0 \n\nand have your desired set of submodules there.\nCombined with the changes in the attr system, b0db704652\n(pathspec: allow querying for attributes, 2017-03-13)\nyou could make up things like this:\n\n $ cat .gitattributes\n /sub0 label0\n /sub1\n /sub2 label1 label2\n /sub3 label1\n /platform-specifc-subs/* label1 label2\n\nand then get a clone via\n\n git clone --recurse=:(attr:label2). \n\nfor example. The labeling via the attributes allows for\ncomplex patterns, but a relatively easy command line, that you\ncan share with coworkers.\n\n> Is this intentional? Something in the git/git test harness seems to prevent\n> that. I was not able to write a test to replicate the issue.\n>\n> Any idea?\n\nI do not seem to understand the perceived bug?\nThe setting of submodule.active= seems intentional to me,\nbut how would you not reproduce it? Maybe Brandon has an idea.\n\nThanks,\nStefan\n"},{"id":"326950","messageId":"CAGZ79kbwJN_XVcAbkyVJTax9F2NR4EO8XjR3U9EH8MLqbAb90Q@mail.gmail.com","threadId":"46606","inReplyTo":"20170822153311.GA5697@book.hvoigt.net","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-22T18:10:52Z","receivedAt":"2017-08-22T18:11:00Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:\n> On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:\n>> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n>> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n>> >> As long as we are talking about idealized future world (well, at\n>> >> least an idea of somebody's \"ideal\", not necessarily shared by\n>> >> everybody), I wonder if there is even any need to have commits in\n>> >> submodules in such a world. To realize such a \"monorepo\" world, you\n>> >> might be better off allowing a gitlink in the superproject to\n>> >> directly point at a tree object in a submodule repository (making\n>> >> them physically a single repository is an optional implementation\n>> >> detail I choose to ignore in this discussion).\n>> >\n>> > IMO this is one step to far. One main use of submodules are shared\n>> > repositories that are used by many superprojects. The reason you want to\n>> > have commits in the submodule are so that you can push them\n>> > independently and all other users can pick up the changes. You could get\n>> > by by Using the superproject commits for the submodule once you push or\n>> > something but those do not necessarily make sense in the context of the\n>> > submodule.\n>> >\n>> > So I think it is important that there are commits in the submodule so\n>> > its history makes sense independently for others.\n>> >\n>> > Or how would you push out the history in the submodule in your idea?\n>> > Maybe I am missing something? What would be your use case with gitlinks\n>> > pointing to trees?\n>>\n>> Well there are still commits, but in the superproject the UX feels more\n>> as if the submodules were special trees.\n>\n> Ah ok then I misunderstood. So they only feel like trees.\n>\n>> So if you want to interact with\n>> the submodule specifically, you could do things like\n>>\n>> git add /path/inside/sub\n>> # works seamlessly from the superproject tree\n>\n> Would that mean that we need to loosen/keep the requirement loose for a\n> name from .gitmodules? I am asking because of my series for on-demand\n> fetch of renamed submodules. For the full functionality I would require\n> a name.\n>\n> Would that be in a scenario where the user would then e.g. push the\n> submodule into the superproject?\n>\n> Ah wait I misunderstood again. You mean a file in an existing\n> submodule right? Not adding submodule from a repository a user moved\n> there?\n\nAssuming the submodule is at /path in this example, the effect of\nthat command could be achieved today via\n\n git -C /path add inside/sub\n\n(i.e. for git-add we \"just\" detect that there is a submodule boundary\nand run the git-add inside the submodule)\n\n>\n>> git commit --submodule-commit-only\n>> # When the flag is not give, you may get an editor\n>> # asking for two commit messages, (sub+super)\n>\n> Or maybe something like\n>\n> git commit --submodule path/to/submodule\n\nYes. In todays UX, you do\n\n git -C path/to/submodule commit\n\nfor the command that you proposed. For a plain\ngit-commit in the superproject, we could envision\nthis sequence of todays commands:\n\n git -C submodule commit\n git add submodule\n git commit\n\n>\n> so the user can specify which submodule she wants. I first wrote it\n> without the switch but but that collides with listing files which should\n> be added. IMO this shorter option is also more intuitive to understand\n> what it does (for this case).\n>\n>> git fetch --submodule\n>> # When the flag is not given, we'd fetch superproject and\n>> # on-demand\n>\n> Yes like above we should add the path to the submodule right?\n\nyes.\n\n>\n>> # You feel the superproject is in the way?\n>> git worktree add --for-submodule ...\n>> # The new submodule worktree puts the\n>> # submodule only UX first. so it feels like its own\n>> # repository, no need for specific flags.\n>\n> I am not sure I understand this one. What would that do? Put a worktree\n> for submodule path/to/sub to ...?\n\nYes, and at \"...\" you would have the UX of the submodule being\nits own repository, no interaction with the superproject.\n\n>\n> Overall I like the direction of these ideas.\n>\n> Cheers Heiko\n"},{"id":"326954","messageId":"20170822185543.GA114773@google.com","threadId":"46606","inReplyTo":"CAGZ79kbpf-a_ZinPLuPh2Vq629=cQknuLVF-QVwOeae1ZGS2Cw@mail.gmail.com","subject":"Re: [PATCH] pull: respect submodule update configuration","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-08-22T18:55:43Z","receivedAt":"2017-08-22T18:55:51Z","isPatch":true,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 08/22, Stefan Beller wrote:\n> On Tue, Aug 22, 2017 at 7:50 AM, Lars Schneider\n> wrote:\n> >\n> > OK. I change my scripts to use \".active\" and it seems to work nicely.\n> >\n> > I noticed one oddity, though:\n> >\n> > If I clone a repo using `git clone --recursive ` then the local\n> > Git config of the repo gets the following entry:\n> >\n> > [submodule]\n> > active = .\n> \n> bb62e0a99f (clone: teach --recurse-submodules to optionally take a\n> pathspec, 2017-03-17) makes it clear that this is intentional for\n> --recurse-submodules, but doesn't exactly state that --recurse will\n> behave the same. The idea here is that at clone time you can already\n> give\n> \n> git clone --recurse=:(exclude)sub0 \n> \n> and have your desired set of submodules there.\n> Combined with the changes in the attr system, b0db704652\n> (pathspec: allow querying for attributes, 2017-03-13)\n> you could make up things like this:\n> \n> $ cat .gitattributes\n> /sub0 label0\n> /sub1\n> /sub2 label1 label2\n> /sub3 label1\n> /platform-specifc-subs/* label1 label2\n> \n> and then get a clone via\n> \n> git clone --recurse=:(attr:label2). \n> \n> for example. The labeling via the attributes allows for\n> complex patterns, but a relatively easy command line, that you\n> can share with coworkers.\n> \n> > Is this intentional? Something in the git/git test harness seems to prevent\n> > that. I was not able to write a test to replicate the issue.\n> >\n> > Any idea?\n> \n> I do not seem to understand the perceived bug?\n> The setting of submodule.active= seems intentional to me,\n> but how would you not reproduce it? Maybe Brandon has an idea.\n> \n\nWhen adding '.active' we wanted it to be as flexible as possible. So\nyou can either use a pathspec with 'submodule.active' to catch multiple\nsubmodules as being active or you can turn on/off individual submodules\nwith 'submodule..active' (this has precedent over the more general\n'submodule.active' config).\n\nThe intent was if a user supplies --recurse-submodules (I believe i\nremoved the docs for --recursive in order to make the CLI more consistent\nwith other commands, so --recursive is just a synonym for\n--recurse-submodules) then they clearly wanted all the submodules cloned\nand checked out. With the '.active' config the way to specify this\nis to make 'submodule.active = .'. In the old world every submodule\nwould need to have its URL copied into the config. This way the config\nis kept cleaner as it only has a single entry added.\n\nAs stefan mentioned you can specify a value for 'submodule.active' to\ntake as an arg to --recurse-submodules (the default being '.' or all\nsubmodules) so you can do clever things like group submodules using\nattributes, you can even repeat the flag to provided a more complex\npathspec.\n\nHopefully that answers your question :D\n\n-- \nBrandon Williams\n"},{"id":"327175","messageId":"20170825091048.GB14872@book.hvoigt.net","threadId":"46606","inReplyTo":"CAGZ79kbwJN_XVcAbkyVJTax9F2NR4EO8XjR3U9EH8MLqbAb90Q@mail.gmail.com","subject":"Re: Submodule regression in 2.14?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2017-08-25T09:10:48Z","receivedAt":"2017-08-25T09:11:00Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:\n> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:\n> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:\n> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n> >> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n> >> # You feel the superproject is in the way?\n> >> git worktree add --for-submodule ...\n> >> # The new submodule worktree puts the\n> >> # submodule only UX first. so it feels like its own\n> >> # repository, no need for specific flags.\n> >\n> > I am not sure I understand this one. What would that do? Put a worktree\n> > for submodule path/to/sub to ...?\n> \n> Yes, and at \"...\" you would have the UX of the submodule being\n> its own repository, no interaction with the superproject.\n\nAre you sure that is what Junio meant? IMO that would be 'git worktree\nclone' or 'git worktree checkout', no? In todays git terminology an\n'add' is something that puts data into the repository / the index. That\nis why I was/am confused.\n\nCheers Heiko\n"},{"id":"327190","messageId":"CAGZ79kbYWyAkxbRv8vw9woR_KSSNRgjWhjkU3wwAGZfpFakhwA@mail.gmail.com","threadId":"46606","inReplyTo":"20170825091048.GB14872@book.hvoigt.net","subject":"Re: Submodule regression in 2.14?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-25T16:38:12Z","receivedAt":"2017-08-25T16:38:18Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, Aug 25, 2017 at 2:10 AM, Heiko Voigt wrote:\n> On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:\n>> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:\n>> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:\n>> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n>> >> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n>> >> # You feel the superproject is in the way?\n>> >> git worktree add --for-submodule ...\n>> >> # The new submodule worktree puts the\n>> >> # submodule only UX first. so it feels like its own\n>> >> # repository, no need for specific flags.\n>> >\n>> > I am not sure I understand this one. What would that do? Put a worktree\n>> > for submodule path/to/sub to ...?\n>>\n>> Yes, and at \"...\" you would have the UX of the submodule being\n>> its own repository, no interaction with the superproject.\n>\n> Are you sure that is what Junio meant?\n\nI am not sure at all, what Junio thought about this.\n\n> IMO that would be 'git worktree\n> clone' or 'git worktree checkout', no? In todays git terminology an\n> 'add' is something that puts data into the repository / the index. That\n> is why I was/am confused.\n\nI went with current gits:\n$ git worktree\nusage: git worktree add [] []\n or: git worktree list []\n or: git worktree lock [] \n or: git worktree prune []\n or: git worktree unlock \n\nwhere the 'add' adds a new worktree (my mental emphasis was on the\noption that says: \"Make the new worktree for the submodule, such\nthat in that worktree the submodule feels like the toplevel\nrepository\". If 'add' is a bad naming choice, we may want to\ndiscuss&deprecate it in a new thread as that is related to the\nworktree area?)\n\nThanks,\nStefan\n\n>\n> Cheers Heiko\n"},{"id":"327192","messageId":"xmqqk21rtwq8.fsf@gitster.mtv.corp.google.com","threadId":"46606","inReplyTo":"20170825091048.GB14872@book.hvoigt.net","subject":"Re: Submodule regression in 2.14?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-25T16:53:35Z","receivedAt":"2017-08-25T16:53:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> On Tue, Aug 22, 2017 at 11:10:52AM -0700, Stefan Beller wrote:\n>> On Tue, Aug 22, 2017 at 8:33 AM, Heiko Voigt wrote:\n>> > On Mon, Aug 21, 2017 at 09:42:54AM -0700, Stefan Beller wrote:\n>> >> On Mon, Aug 21, 2017 at 9:05 AM, Heiko Voigt wrote:\n>> >> > On Fri, Aug 18, 2017 at 11:51:13PM -0700, Junio C Hamano wrote:\n>> >> # You feel the superproject is in the way?\n>> >> git worktree add --for-submodule ...\n>> >> # The new submodule worktree puts the\n>> >> # submodule only UX first. so it feels like its own\n>> >> # repository, no need for specific flags.\n>> >\n>> > I am not sure I understand this one. What would that do? Put a worktree\n>> > for submodule path/to/sub to ...?\n>> \n>> Yes, and at \"...\" you would have the UX of the submodule being\n>> its own repository, no interaction with the superproject.\n>\n> Are you sure that is what Junio meant?\n\nI am sure it was not. \n\nIf adding a separate worktree only for one submodule, you should be\nable to \"cd $path-to-submodule\" and run \"git worktree add\" to create\na new worktree, and I do not see any reason for the superproject to\nget involved in that process. Does it have more information ready\nthan the end user has to help the process of creating a new worktree?\n\nWhile I can understand how --for-submodule above may be implemented,\nI do not see the point of adding such an option.\n\n\n\n\n"}]}