{"thread":{"id":"44091","subject":"[wishlist?] make submodule commands robust to having non-submodule Subprojects","startedAt":"2016-09-15T13:03:00Z","lastAt":"2016-09-16T18:29:00Z","messageCount":13,"participants":["Yaroslav Halchenko","Stefan Beller","Junio C Hamano","Heiko Voigt","Jacob Keller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"301961","messageId":"20160915130233.GC9833@onerussian.com","threadId":"44091","inReplyTo":null,"subject":"[wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-09-15T13:02:33Z","receivedAt":"2016-09-15T13:03:00Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"NB echos some questions of mine a few days back on IRC about Subprojects\nand submodules \n\nIf e.g. you just 'git add' a subdirectory which is a git repository, git\nadds it as a subproject but doesn't initiate any entry in .gitmodules\nsince it is the job done by submodule and git core itself is\nagnostic of those beasts.\n\nBut having then this \"Subproject\"s which aren't registered as submodules\n(and I haven't found any other use for them besides being a submodule)\nbrakes \"git submodule\" commands, e.g.\n\n$> git submodule\n cc6a09ac06c13cf06b4f4c8b54cda9a535e4e385 ds000001 (2.0.0+4)\n 0a9f3b66e06a2137311a537b7377c336f1fb30ad ds000002 (1.0.0-3-g0a9f3b6)\n 9da7e4f4221699915645ac2003298c6aba2db109 ds000003 (1.1.0+4)\n fe16cacb5cb9b4d53c50e498298fab182500e147 ds000005 (2.0.0+3)\n 6898d99ff3ba26880183ed3672a458a7fcde1737 ds000006 (2.0.0+2)\n bbd10f634fe87e9d5853df3a891edbdb18cda7f9 ds000007 (2.0.0+3)\n 138e6730193c0585a69b8baf5b9d7a4439e83ecc ds000008 (2.0.0+2)\n ddf3a4cf7ce51a01a664e6faff4b8334b8414b1f ds000009 (2.0.1+1)\n 7fa73b4df8166dba950c7dc07c3f8cdd50fca313 ds000011 (1.0.0-5-g7fa73b4)\nfatal: no submodule mapping found in .gitmodules for path 'ds000017\n\nwhich then stops without even looking at other submodules.\n\nI think it would be more logical to make it a 'warning:' not a 'fatal:' and\nproceed.\n\nThank you for consideration\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"301978","messageId":"CAGZ79kZLdsKcf0t=dDB24VVe+V=uqQCW_VNQwSJ638m5Keu2nQ@mail.gmail.com","threadId":"44091","inReplyTo":"20160915130233.GC9833@onerussian.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-09-15T16:05:10Z","receivedAt":"2016-09-15T16:05:19Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Sep 15, 2016 at 6:02 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:\n> NB echos some questions of mine a few days back on IRC about Subprojects\n> and submodules\n>\n> If e.g. you just 'git add' a subdirectory which is a git repository, git\n> adds it as a subproject but doesn't initiate any entry in .gitmodules\n> since it is the job done by submodule and git core itself is\n> agnostic of those beasts.\n>\n> But having then this \"Subproject\"s which aren't registered as submodules\n> (and I haven't found any other use for them besides being a submodule)\n> brakes \"git submodule\" commands, e.g.\n>\n> $> git submodule\n>  cc6a09ac06c13cf06b4f4c8b54cda9a535e4e385 ds000001 (2.0.0+4)\n>  0a9f3b66e06a2137311a537b7377c336f1fb30ad ds000002 (1.0.0-3-g0a9f3b6)\n>  9da7e4f4221699915645ac2003298c6aba2db109 ds000003 (1.1.0+4)\n>  fe16cacb5cb9b4d53c50e498298fab182500e147 ds000005 (2.0.0+3)\n>  6898d99ff3ba26880183ed3672a458a7fcde1737 ds000006 (2.0.0+2)\n>  bbd10f634fe87e9d5853df3a891edbdb18cda7f9 ds000007 (2.0.0+3)\n>  138e6730193c0585a69b8baf5b9d7a4439e83ecc ds000008 (2.0.0+2)\n>  ddf3a4cf7ce51a01a664e6faff4b8334b8414b1f ds000009 (2.0.1+1)\n>  7fa73b4df8166dba950c7dc07c3f8cdd50fca313 ds000011 (1.0.0-5-g7fa73b4)\n> fatal: no submodule mapping found in .gitmodules for path 'ds000017\n>\n> which then stops without even looking at other submodules.\n>\n> I think it would be more logical to make it a 'warning:' not a 'fatal:' and\n> proceed.\n\nSo maybe we would want to introduce a switch\n  `--existing-but-unconfigure-gitlinks=(warn|ignore)`\nas well as\n`git config submodule.existing-but-unconfigured (warn|ignore)`\nfor a more permanent solution?\n\n\n\n>\n> Thank you for consideration\n> --\n> Yaroslav O. Halchenko\n> Center for Open Neuroscience     http://centerforopenneuroscience.org\n> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\n> Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\n> WWW:   http://www.linkedin.com/in/yarik\n"},{"id":"301980","messageId":"20160915164035.GL9830@onerussian.com","threadId":"44091","inReplyTo":"CAGZ79kZLdsKcf0t=dDB24VVe+V=uqQCW_VNQwSJ638m5Keu2nQ@mail.gmail.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-09-15T16:40:35Z","receivedAt":"2016-09-15T16:40:42Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Thu, 15 Sep 2016, Stefan Beller wrote:\n\n> > I think it would be more logical to make it a 'warning:' not a 'fatal:' and\n> > proceed.\n\n> So maybe we would want to introduce a switch\n>   `--existing-but-unconfigure-gitlinks=(warn|ignore)`\n> as well as\n> `git config submodule.existing-but-unconfigured (warn|ignore)`\n> for a more permanent solution?\n\npossibly ignorant question:  is  gitlink === Subproject    or a\nSubproject is a kinda of a gitlink and there are other gitlinks which\naren't Subprojects? ;)\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"301982","messageId":"CAGZ79kYDpF5C6dXoi9ghmy40XDK1Gz-8HjmKQ_m_v_pUS1ZmDA@mail.gmail.com","threadId":"44091","inReplyTo":"20160915164035.GL9830@onerussian.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-09-15T17:29:49Z","receivedAt":"2016-09-15T17:29:56Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Sep 15, 2016 at 9:40 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:\n>\n> On Thu, 15 Sep 2016, Stefan Beller wrote:\n>\n>> > I think it would be more logical to make it a 'warning:' not a 'fatal:' and\n>> > proceed.\n>\n>> So maybe we would want to introduce a switch\n>>   `--existing-but-unconfigure-gitlinks=(warn|ignore)`\n>> as well as\n>> `git config submodule.existing-but-unconfigured (warn|ignore)`\n>> for a more permanent solution?\n>\n> possibly ignorant question:  is  gitlink === Subproject    or a\n> Subproject is a kinda of a gitlink and there are other gitlinks which\n> aren't Subprojects? ;)\n>\n\ngitlink is the internal name (just like a file is called blob, or a directory is\ncalled tree; there is no file system equivalent for e.g. commits, or\ngitlinks)\n\ngitlinks as a basic building block only points at a sha1 to be part of\nthe repository.\n\nSubmodules use gitlinks to point at (usually) different projects, e.g.\na library.\n\nSubprojects in Git is a loose term, it could mean submodule or part of your\nrepo merged in via the git-subtree command. Or a sub project can\nbe just a loose repository inside your repository.\n\ngitlinks do not necessarily need to track other projects; it's \"just a pointer\"\nto a specific version of a repository.\n\nSo to come back to your question: yeah In that response I meant\nsubmodule==gitlink, though naming the internal data structure to be\nmore explicit. (What if we invent a new way to do submodules not\nusing gitlinks? Then that config option may be less confusing and\nbackwards compatible. That is unlikely though. So I guess we'll settle\nwith a different name)\n"},{"id":"301986","messageId":"xmqqwpidniry.fsf@gitster.mtv.corp.google.com","threadId":"44091","inReplyTo":"CAGZ79kZLdsKcf0t=dDB24VVe+V=uqQCW_VNQwSJ638m5Keu2nQ@mail.gmail.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-15T18:02:25Z","receivedAt":"2016-09-15T18:02:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n> On Thu, Sep 15, 2016 at 6:02 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:\n>>\n>> If e.g. you just 'git add' a subdirectory which is a git repository, git\n>> adds it as a subproject but doesn't initiate any entry in .gitmodules\n>> since it is the job done by submodule and git core itself is\n>> agnostic of those beasts.\n>> ...\n>> $> git submodule\n>>  cc6a09ac06c13cf06b4f4c8b54cda9a535e4e385 ds000001 (2.0.0+4)\n>>  0a9f3b66e06a2137311a537b7377c336f1fb30ad ds000002 (1.0.0-3-g0a9f3b6)\n>>  9da7e4f4221699915645ac2003298c6aba2db109 ds000003 (1.1.0+4)\n>>  fe16cacb5cb9b4d53c50e498298fab182500e147 ds000005 (2.0.0+3)\n>>  6898d99ff3ba26880183ed3672a458a7fcde1737 ds000006 (2.0.0+2)\n>>  bbd10f634fe87e9d5853df3a891edbdb18cda7f9 ds000007 (2.0.0+3)\n>>  138e6730193c0585a69b8baf5b9d7a4439e83ecc ds000008 (2.0.0+2)\n>>  ddf3a4cf7ce51a01a664e6faff4b8334b8414b1f ds000009 (2.0.1+1)\n>>  7fa73b4df8166dba950c7dc07c3f8cdd50fca313 ds000011 (1.0.0-5-g7fa73b4)\n>> fatal: no submodule mapping found in .gitmodules for path 'ds000017\n>>\n>> which then stops without even looking at other submodules.\n>>\n>> I think it would be more logical to make it a 'warning:' not a 'fatal:' and\n>> proceed.\n\nMaking \"git submodule\" listing to continue from that point may be\none thing, but do we have a sensible way in \"git submodule add\" to\nallow the user to recover from this condition?  That is, \"git add\"\nis a right way to tell the core level that there is a gitlink, but\nas Yaroslav correctly observed in the early part of his message,\nhaving that gitlink alone is not good enough for the world view of \n\"git submodule\" that sits at higher-layer.  And the usual way to\ntell the submodule layer that there is a submodule is with \"git\nsubmodule add\", but\n\n\t$ git init top\n        $ cd top\n        $ git commit --allow-empty -m 'initial in top'\n        $ git init sub\n        $ git -C sub commit --allow-empty -m 'initial in sub'\n\n        $ git add sub\n\t$ git submodule\n        fatal: no submodule mapping found in .gitmodules for path 'sub'\n\n\t$ git submodule add ./sub sub\n        'sub' already exists in the index\n\t$ git submodule add -f ./sub sub\n        'sub' already exists in the index\n\nI highly suspect that the user will then get stuck at this point,\nafter trying to \"submodule add\" and then even attempting to force\nit.\n\nI think that is a more pressing thing to address.  Once we make it\neasier for the user to bring a half-initialized submodule properly\ninto the world view of the submodule subsystem, we would have to\nworry about the reported failure case even less and you do not need \nto pile on workaround options to let things continue in a state that\nis half-broken (that is, in a state that is perfectly sane to the\ncore layer, but is not liked by the submodule layer).\n\n"},{"id":"301987","messageId":"20160915181254.GN9830@onerussian.com","threadId":"44091","inReplyTo":"xmqqwpidniry.fsf@gitster.mtv.corp.google.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Yaroslav Halchenko","fromEmail":"yoh@onerussian.com","sentAt":"2016-09-15T18:12:54Z","receivedAt":"2016-09-15T18:13:03Z","isPatch":false,"sender":{"key":"yoh@onerussian.com","avatar":"https://gravatar.com/avatar/8901b82415ae451a83aea49409708912726e53620e3ac92320bf1f86548d97e9?d=mp&s=160"},"body":"\nOn Thu, 15 Sep 2016, Junio C Hamano wrote:\n\n> >> which then stops without even looking at other submodules.\n\n> >> I think it would be more logical to make it a 'warning:' not a 'fatal:' and\n> >> proceed.\n\n> Making \"git submodule\" listing to continue from that point may be\n> one thing, but do we have a sensible way in \"git submodule add\" to\n> allow the user to recover from this condition?  That is, \"git add\"\n> is a right way to tell the core level that there is a gitlink, but\n> as Yaroslav correctly observed in the early part of his message,\n> having that gitlink alone is not good enough for the world view of \n> \"git submodule\" that sits at higher-layer.  And the usual way to\n> tell the submodule layer that there is a submodule is with \"git\n> submodule add\", but\n\n> \t$ git init top\n>         $ cd top\n>         $ git commit --allow-empty -m 'initial in top'\n>         $ git init sub\n>         $ git -C sub commit --allow-empty -m 'initial in sub'\n\n>         $ git add sub\n> \t$ git submodule\n>         fatal: no submodule mapping found in .gitmodules for path 'sub'\n\n> \t$ git submodule add ./sub sub\n>         'sub' already exists in the index\n> \t$ git submodule add -f ./sub sub\n>         'sub' already exists in the index\n\nFWIW\nI could have sworn that I have tried to 'submodule add' it and it\nworked... but pragmatically I just did edit .gitmodules, added the\nrecord for it, committed it, and then iirc git submodule update --init\nwhich seemed to make  git happy... FTR:\n\n$> git submodule add ./sub ./sub\n'sub' already exists in the index\n\n$> git submodule add ./sub/ ./sub/\n'sub' already exists in the index\n\n$> vim .gitmodules\n\n$> git add .gitmodules\ncached/staged changes:                                                                                                                                                                                                                                                                                            \n .gitmodules | 4 ++++\n sub         | 1 +\n\n$> git submodule update --init\nSubmodule 'sub' (/tmp/111/top/sub) registered for path 'sub'\ncached/staged changes:                                                                                                                                                                                                                                                                                            \n .gitmodules | 4 ++++\n sub         | 1 +\n\n$> git commit -m 'added finally'\n[master aa6d912] added finally\n 2 files changed, 5 insertions(+)\n create mode 100644 .gitmodules\n create mode 160000 sub\n\n$> git submodule\n 6f574b298ef51aebd36daafad450a3e38802ca03 sub (heads/master)\n\n\n> I highly suspect that the user will then get stuck at this point,\n> after trying to \"submodule add\" and then even attempting to force\n> it.\n\n> I think that is a more pressing thing to address.  Once we make it\n> easier for the user to bring a half-initialized submodule properly\n> into the world view of the submodule subsystem, we would have to\n> worry about the reported failure case even less and you do not need \n> to pile on workaround options to let things continue in a state that\n> is half-broken (that is, in a state that is perfectly sane to the\n> core layer, but is not liked by the submodule layer).\n\ndo you foresee any unpleasant side-effects from above manual editing\n.gitmodules/submodule update --init ?\n\n-- \nYaroslav O. Halchenko\nCenter for Open Neuroscience     http://centerforopenneuroscience.org\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"301988","messageId":"CAGZ79kbYEqbr0h_0U=Ed-NRrsjb4XmznL8C45gTyJCVx+X-LTQ@mail.gmail.com","threadId":"44091","inReplyTo":"xmqqwpidniry.fsf@gitster.mtv.corp.google.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-09-15T18:15:16Z","receivedAt":"2016-09-15T18:15:23Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Sep 15, 2016 at 11:02 AM, Junio C Hamano <gitster@pobox.com> wrote:\n\n> I think that is a more pressing thing to address.  Once we make it\n> easier for the user to bring a half-initialized submodule properly\n> into the world view of the submodule subsystem, we would have to\n> worry about the reported failure case even less and you do not need\n> to pile on workaround options to let things continue in a state that\n> is half-broken (that is, in a state that is perfectly sane to the\n> core layer, but is not liked by the submodule layer).\n\nHeh, I see.\n\n    When searching around the net, some people use half\n    initialized submodules intentionally, e.g. I'll store some private keys in\n    sub and I publish the superproject asking for collaborators to my new shiny\n    webbased thing. The submodule containing the private keys never leaves\n    my hard drive, hence no .gitmodules entry is necessary.\n\nNot sure I agree with such a setup, but people use it.\n\nSo how about this fictional work flow:\n\n         $ git init top\n         $ cd top\n         $ git commit --allow-empty -m 'initial in top'\n         $ git init sub\n         $ git -C sub commit --allow-empty -m 'initial in sub'\n         $ git add sub\n        You added a gitlink, but no corresponding entry in\n        .gitmodules is found. This is fine for gits core functionality, but\n        the submodule command gets confused by this unless you add 'sub'\n        to your .gitmodules via `git submodule add --already-in-tree \\\n        --reuse-submodules-origin-as-URL sub`. Alternatively you can make this\n        message disappear by configuring advice.gitlinkPitfalls.\n\n         $ git submodule\n         ... similar advice goes here...\n         fatal: no submodule mapping found in .gitmodules for path 'sub'\n\n         $ git submodule add --fixup-modules-file ./sub sub\n         Adding .gitmodule entry only for `sub` to use `git -C remote\nshow origin` as URL.\n\n         # user is happy now.\n"},{"id":"301989","messageId":"CAGZ79kYrFnAM97AqRN2e8s411wniT8QGqopC7vsZ=7ZJV=zwMQ@mail.gmail.com","threadId":"44091","inReplyTo":"20160915181254.GN9830@onerussian.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-09-15T18:16:53Z","receivedAt":"2016-09-15T18:16:58Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Sep 15, 2016 at 11:12 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:\n\n>\n> do you foresee any unpleasant side-effects from above manual editing\n> .gitmodules/submodule update --init ?\n\nI think that is fine, but un(der)documented. So you have to figure it out\nfrom experience what to do exactly.\n"},{"id":"301990","messageId":"xmqqsht1nhlh.fsf@gitster.mtv.corp.google.com","threadId":"44091","inReplyTo":"CAGZ79kbYEqbr0h_0U=Ed-NRrsjb4XmznL8C45gTyJCVx+X-LTQ@mail.gmail.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-15T18:27:54Z","receivedAt":"2016-09-15T18:28:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n>     When searching around the net, some people use half\n>     initialized submodules intentionally,...\n>\n> Not sure I agree with such a setup, but people use it.\n\nIn such a top-level project, people would not use \"git submodule\"\ncommand, would they?  I do not think anybody in this thread was\npushing to forbid such a use, and it may be perfectly fine if \"git\nsubmodule\" does not work for such a gitlink; after all such a\nsubdirectory is not even meant to be a submodule.\n\n> So how about this fictional work flow:\n>\n>          $ git init top\n>          $ cd top\n>          $ git commit --allow-empty -m 'initial in top'\n>          $ git init sub\n>          $ git -C sub commit --allow-empty -m 'initial in sub'\n>          $ git add sub\n>         You added a gitlink, but no corresponding entry in\n>         .gitmodules is found. This is fine for gits core functionality, but\n>         the submodule command gets confused by this unless you add 'sub'\n>         to your .gitmodules via `git submodule add --already-in-tree \\\n>         --reuse-submodules-origin-as-URL sub`. Alternatively you can make this\n>         message disappear by configuring advice.gitlinkPitfalls.\n\nI am not sure if I agree with that direction.\n\nIf the trend in Git community collectively these days is to make\nusage of submodules easier and smoother, I'd imagine that you would\nwant to teach \"git add\" that was given a submodule to \"git submodule\nadd\" instead by default, with an option \"git add --no-gitmodules\nsub\" to disable it, or something like that.\n\n>          $ git submodule add --fixup-modules-file ./sub sub\n>          Adding .gitmodule entry only for `sub` to use `git -C remote\n> show origin` as URL.\n\nI agree that a feature like this is needed regardless of what\nhappens at \"git add\" time.\n"},{"id":"301991","messageId":"xmqqoa3pnhjn.fsf@gitster.mtv.corp.google.com","threadId":"44091","inReplyTo":"20160915181254.GN9830@onerussian.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-15T18:29:00Z","receivedAt":"2016-09-15T18:29:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yaroslav Halchenko <yoh@onerussian.com> writes:\n\n> do you foresee any unpleasant side-effects from above manual editing\n> .gitmodules/submodule update --init ?\n\nI do not think so; you essentially did what a canned command we\nshould have had should have done by hand because of a lack of such a\nfeature.\n"},{"id":"302052","messageId":"20160916141143.GA47240@book.hvoigt.net","threadId":"44091","inReplyTo":"xmqqsht1nhlh.fsf@gitster.mtv.corp.google.com","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2016-09-16T14:11:43Z","receivedAt":"2016-09-16T14:12:40Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote:\n> Stefan Beller <sbeller@google.com> writes:\n> > So how about this fictional work flow:\n> >\n> >          $ git init top\n> >          $ cd top\n> >          $ git commit --allow-empty -m 'initial in top'\n> >          $ git init sub\n> >          $ git -C sub commit --allow-empty -m 'initial in sub'\n> >          $ git add sub\n> >         You added a gitlink, but no corresponding entry in\n> >         .gitmodules is found. This is fine for gits core functionality, but\n> >         the submodule command gets confused by this unless you add 'sub'\n> >         to your .gitmodules via `git submodule add --already-in-tree \\\n> >         --reuse-submodules-origin-as-URL sub`. Alternatively you can make this\n> >         message disappear by configuring advice.gitlinkPitfalls.\n> \n> I am not sure if I agree with that direction.\n> \n> If the trend in Git community collectively these days is to make\n> usage of submodules easier and smoother, I'd imagine that you would\n> want to teach \"git add\" that was given a submodule to \"git submodule\n> add\" instead by default, with an option \"git add --no-gitmodules\n> sub\" to disable it, or something like that.\n> \n> >          $ git submodule add --fixup-modules-file ./sub sub\n> >          Adding .gitmodule entry only for `sub` to use `git -C remote\n> > show origin` as URL.\n> \n> I agree that a feature like this is needed regardless of what\n> happens at \"git add\" time.\n\nHow about just\n\n   git submodule add <submodulepath>\n\n? I remember back in the days when I started with submodules thats the\nway I imagined submodules would work:\n\n1. clone the submodule into a directory\n2. git submodule add it\n3. git commit everything\n\nBecause that how you basically work with files.  So instead of adding\nanother option I would rather like to autodetect that:\n\n * its a relative path inside this repo that is passed to\n   'git submodule add'\n * there is no .gitmodules entry\n * and no .git/config\n==> create those from a remote in the submodule\n\nCorner cases:\n\n * If there is more than one remote we could tell the user to use an\n   option to specify which one to use.\n * Barf in case there is no remote (not adding the submodule except -f\n   is used).\n * If the gitlink is already there but no .gitmodules entry, 'git\n   submodule add' will just add the entry as if it was initially added.\n\nInstead of giving an error message that the submodule is already added\nwe could actually be nicer to the user and try to fix things for him\ninstead.\n\nCheers Heiko\n"},{"id":"302053","messageId":"CA+P7+xpyZWqyqnNLaheU=bmyCr3wYFFO3XXKCf56E1-_-sFRAA@mail.gmail.com","threadId":"44091","inReplyTo":"20160916141143.GA47240@book.hvoigt.net","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-09-16T15:40:27Z","receivedAt":"2016-09-16T15:40:53Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Sep 16, 2016 at 7:11 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:\n> How about just\n>\n>    git submodule add <submodulepath>\n>\n> ? I remember back in the days when I started with submodules thats the\n> way I imagined submodules would work:\n>\n> 1. clone the submodule into a directory\n> 2. git submodule add it\n> 3. git commit everything\n>\n> Because that how you basically work with files.  So instead of adding\n> another option I would rather like to autodetect that:\n>\n>  * its a relative path inside this repo that is passed to\n>    'git submodule add'\n>  * there is no .gitmodules entry\n>  * and no .git/config\n> ==> create those from a remote in the submodule\n>\n> Corner cases:\n>\n>  * If there is more than one remote we could tell the user to use an\n>    option to specify which one to use.\n>  * Barf in case there is no remote (not adding the submodule except -f\n>    is used).\n>  * If the gitlink is already there but no .gitmodules entry, 'git\n>    submodule add' will just add the entry as if it was initially added.\n>\n> Instead of giving an error message that the submodule is already added\n> we could actually be nicer to the user and try to fix things for him\n> instead.\n>\n\nThis makes sense to me. Possibly we could warn in this case, so that\nthe user knows that something was \"off\" but I don't think we should be\nfailing here...\n\nRegards,\nJake\n\n> Cheers Heiko\n"},{"id":"302066","messageId":"xmqqwpibk8bg.fsf@gitster.mtv.corp.google.com","threadId":"44091","inReplyTo":"20160916141143.GA47240@book.hvoigt.net","subject":"Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-09-16T18:28:51Z","receivedAt":"2016-09-16T18:29:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt <hvoigt@hvoigt.net> writes:\n\n> On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote:\n>\n>> If the trend in Git community collectively these days is to make\n>> usage of submodules easier and smoother, I'd imagine that you would\n>> want to teach \"git add\" that was given a submodule to \"git submodule\n>> add\" instead by default, with an option \"git add --no-gitmodules\n>> sub\" to disable it, or something like that.\n>> \n>> >          $ git submodule add --fixup-modules-file ./sub sub\n>> >          Adding .gitmodule entry only for `sub` to use `git -C remote\n>> > show origin` as URL.\n>> \n>> I agree that a feature like this is needed regardless of what\n>> happens at \"git add\" time.\n>\n> How about just\n>\n>    git submodule add <submodulepath>\n\nWhen I said \"a feature like this is needed\", I didn't care about\nexact syntax.  I am not sure how often people need the \"fixup\", what\nkind of causes there are that they need the \"fixup\", and what the\ndistribution of vaious causes would be like.  If the _ONLY_ kind of\nfixup necessary is \"I meant to say 'git submodule add ./path path'\nbut I said 'git add path' instead\", then I think it makes sense to\nteach \"submodule add\" that the form \"git submodule add <path>\" is a\nshort-pand for \"git submodule add ./<path> <path>\".  I am not sure\nif we want to _ignore_ a gitlink that is already in the index\nunconditionally, i.e. if it is a good idea to let the second one\noverride the first one\n\n\tgit submodule add $URL sub &&\n        git submodule add sub\n\nin this sequence, though.\n\n> ? I remember back in the days when I started with submodules thats the\n> way I imagined submodules would work:\n>\n> 1. clone the submodule into a directory\n> 2. git submodule add it\n> 3. git commit everything\n>\n> Because that how you basically work with files.  So instead of adding\n> another option I would rather like to autodetect that:\n>\n>  * its a relative path inside this repo that is passed to\n>    'git submodule add'\n>  * there is no .gitmodules entry\n>  * and no .git/config\n> ==> create those from a remote in the submodule\n\nIn other words, I agree with the general direction but I'd add\nanother condition to the above three, i.e.\n\n   * and there is no gitlink for that path in the index yet.\n\n"}]}