{"thread":{"id":"33273","subject":"Why does 'submodule add' stage the relevant portions?","startedAt":"2013-03-24T17:38:40Z","lastAt":"2013-03-26T16:57:30Z","messageCount":18,"participants":["Ramkumar Ramachandra","Jens Lehmann","Junio C Hamano","Jonathan Nieder","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"212098","messageId":"CALkWK0=PHNmT5zfjEaWh_5=aV7wcPdGgyCWFhjaeVrrWhL0OBw@mail.gmail.com","threadId":"33273","inReplyTo":null,"subject":"Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-24T17:38:40Z","receivedAt":"2013-03-24T17:38:40Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI find this behavior very inconsistent and annoying.  Why would I want\nto commit the submodule change immediately?  Maybe I want to batch it\nup with other changes and stage it at a later time.  Why should I have\nto unstage them manually now?  I get the other side of the argument:\nwhat if the user commits the .gitmodule change at a different time\nfrom the file change?  In other words, the user should have a way of\nsaying 'submodule stage' and 'submodule unstage'.\n\nNow, for the implementation.  Do we have existing infrastructure to\nstage a hunk non-interactively?  (The ability to select a hunk to\nstage/ unstage programmatically).  If not, it might be quite a\nnon-trivial thing to write.\n\nGit 2.0 is coming soon, so I'm excited about breaking a lot of\nbackward compatibility ;)\n\nThanks.\n\nRam\n"},{"id":"212151","messageId":"51500C67.9040308@web.de","threadId":"33273","inReplyTo":"CALkWK0=PHNmT5zfjEaWh_5=aV7wcPdGgyCWFhjaeVrrWhL0OBw@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-03-25T08:35:51Z","receivedAt":"2013-03-25T08:35:51Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:\n> I find this behavior very inconsistent and annoying.  Why would I want\n> to commit the submodule change immediately?  Maybe I want to batch it\n> up with other changes and stage it at a later time.  Why should I have\n> to unstage them manually now?  I get the other side of the argument:\n> what if the user commits the .gitmodule change at a different time\n> from the file change?  In other words, the user should have a way of\n> saying 'submodule stage' and 'submodule unstage'.\n\nHmm, AFAIK you are the first to bring up such a feature, as in most\nuse cases doing a \"git (submodule) add <path>\" is expected to stage\nwhat you added. Maybe you could teach the stage/unstage code to also\nstage/unstage the corresponding part of the .gitmodules file, but\nI'm not sure it is worth the hassle.\n\n> Now, for the implementation.  Do we have existing infrastructure to\n> stage a hunk non-interactively?  (The ability to select a hunk to\n> stage/ unstage programmatically).  If not, it might be quite a\n> non-trivial thing to write.\n\nHave fun when adding two submodules and unstage only one of them\nlater. I think this feature will not work unless you analyze\n.gitmodules and stage/unstage section-wise.\n"},{"id":"212152","messageId":"CALkWK0kJ2QVA6is85Sdwn1mnGVbuNUSGqg_37WBxPYrepHz9ow@mail.gmail.com","threadId":"33273","inReplyTo":"51500C67.9040308@web.de","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T08:59:47Z","receivedAt":"2013-03-25T08:59:47Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jens Lehmann wrote:\n> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:\n>> I find this behavior very inconsistent and annoying.  Why would I want\n>> to commit the submodule change immediately?  Maybe I want to batch it\n>> up with other changes and stage it at a later time.  Why should I have\n>> to unstage them manually now?  I get the other side of the argument:\n>> what if the user commits the .gitmodule change at a different time\n>> from the file change?  In other words, the user should have a way of\n>> saying 'submodule stage' and 'submodule unstage'.\n>\n> Hmm, AFAIK you are the first to bring up such a feature, as in most\n> use cases doing a \"git (submodule) add <path>\" is expected to stage\n> what you added.\n\nIn my opinion, the 'git submodule add <path>' form is broken, because\nit doesn't relocate the object store of the submodule repository (a\nbug that we need to fix?).  I always use the 'git submodule add\n<repository> <path>' form, which puts the object store of the\nsubmodule repository in .git/modules of the parent repository.  This\nform is nothing like 'git add', but more like a 'git clone': arguably,\n'submodule clone' is a better name for it.\n\n> Maybe you could teach the stage/unstage code to also\n> stage/unstage the corresponding part of the .gitmodules file, but\n> I'm not sure it is worth the hassle.\n\nMaybe not.  I'm still not an heavy user of submodules; I notice many\nbreakages and inconsistencies, but I'm not sure what to fix first, and\nhow to go about fixing it.  I'm yet to look at git-subtree and draw\ninspiration from its design.\n\nMaybe the WTF \"You need to run this command from the toplevel of the\nworking tree\" needs to be fixed first?  I think it's a matter of a\nsimple pushd, popd before the operation and building the correct\nrelative path.  I'm not sure how it'll work with nested submodules\nthough.  Then again, I think nested submodules are Wrong; submodules\nare probably not the right tool for the job.\n\n>> Now, for the implementation.  Do we have existing infrastructure to\n>> stage a hunk non-interactively?  (The ability to select a hunk to\n>> stage/ unstage programmatically).  If not, it might be quite a\n>> non-trivial thing to write.\n>\n> Have fun when adding two submodules and unstage only one of them\n> later. I think this feature will not work unless you analyze\n> .gitmodules and stage/unstage section-wise.\n\nYes, which is why I asked if we have existing infrastructure to make\nthis possible.\n"},{"id":"212183","messageId":"7v38vjz7sx.fsf@alter.siamese.dyndns.org","threadId":"33273","inReplyTo":"CALkWK0=PHNmT5zfjEaWh_5=aV7wcPdGgyCWFhjaeVrrWhL0OBw@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T17:51:58Z","receivedAt":"2013-03-25T17:51:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Git 2.0 is coming soon, so I'm excited about breaking a lot of\n> backward compatibility ;)\n\nDon't.\n\nI lack the sense of humor normal people seem to have, so even with\nthe smiley, anybody making such a comment will be thrown into my \"do\nnot pay attention to them\" box ;-).\n"},{"id":"212186","messageId":"CALkWK0mRnDMFLeVoG85CUZ48rf7X_jHV=0XP73WL7zp2OGpezQ@mail.gmail.com","threadId":"33273","inReplyTo":"7v38vjz7sx.fsf@alter.siamese.dyndns.org","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T18:02:25Z","receivedAt":"2013-03-25T18:02:25Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> Git 2.0 is coming soon, so I'm excited about breaking a lot of\n>> backward compatibility ;)\n>\n> Don't.\n\npush.default is the necessary exception?\n"},{"id":"212193","messageId":"20130325182023.GA1414@google.com","threadId":"33273","inReplyTo":"CALkWK0mRnDMFLeVoG85CUZ48rf7X_jHV=0XP73WL7zp2OGpezQ@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T18:20:23Z","receivedAt":"2013-03-25T18:20:23Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Junio C Hamano wrote:\n>> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of\n>>> backward compatibility ;)\n>>\n>> Don't.\n>\n> push.default is the necessary exception?\n\nA while ago there was a discussion of changes of the \"If we were\nstarting over today, it would be obvious we should have made it work\nthe other way\" kind and potential transition plans for them leading up\nto 2.0.  It's way too late to throw new breakage in.\n\nMore generally, it doesn't make a lot of sense to save thinking about\nsuch questions for the last minute before a new major release.  If an\nimportant change will require breaking compatibility and can only be\ndone using a painful 5-year transition, start today (and send patches\nto the ML when an appropriate quiet moment comes to get review) so the\n5-year counter can start ticking.\n\nHoping that clarifies,\nJonathan\n"},{"id":"212194","messageId":"CALkWK0kx_uQy-97nByNXBOU4UruhvdjOeXCpKHR9mNUQHs5o=A@mail.gmail.com","threadId":"33273","inReplyTo":"20130325182023.GA1414@google.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T18:27:34Z","receivedAt":"2013-03-25T18:27:34Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>> Junio C Hamano wrote:\n>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>>>> Git 2.0 is coming soon, so I'm excited about breaking a lot of\n>>>> backward compatibility ;)\n>>>\n>>> Don't.\n>>\n>> push.default is the necessary exception?\n>\n> A while ago there was a discussion of changes of the \"If we were\n> starting over today, it would be obvious we should have made it work\n> the other way\" kind and potential transition plans for them leading up\n> to 2.0.  It's way too late to throw new breakage in.\n>\n> More generally, it doesn't make a lot of sense to save thinking about\n> such questions for the last minute before a new major release.  If an\n> important change will require breaking compatibility and can only be\n> done using a painful 5-year transition, start today (and send patches\n> to the ML when an appropriate quiet moment comes to get review) so the\n> 5-year counter can start ticking.\n\nI agree that big important changes that break backward compatibility\n(like adding generation numbers to commit objects) will require this\nkind of time and effort to stabilize.  Does a saner push.default\nvalue, or even tweaking the output of 'git status' to show what 'git\nstatus -sb' shows now (git status is porcelain, and no person in the\nright mind will write a script to parse it), require this?  I'm\ntalking about slightly better defaults at the porcelain level, at\nmost.\n"},{"id":"212195","messageId":"7vppynxre7.fsf@alter.siamese.dyndns.org","threadId":"33273","inReplyTo":"CALkWK0kx_uQy-97nByNXBOU4UruhvdjOeXCpKHR9mNUQHs5o=A@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-25T18:31:44Z","receivedAt":"2013-03-25T18:31:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> I'm talking about slightly better defaults at the porcelain level,\n> at most.\n\nIf a change does not even have to break backward compatibilty, that\nis a regular enhancement and independent from 2.0, no?\n"},{"id":"212196","messageId":"51509ABA.3040804@web.de","threadId":"33273","inReplyTo":"CALkWK0kJ2QVA6is85Sdwn1mnGVbuNUSGqg_37WBxPYrepHz9ow@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-03-25T18:43:06Z","receivedAt":"2013-03-25T18:43:06Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:\n> Jens Lehmann wrote:\n>> Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:\n>>> I find this behavior very inconsistent and annoying.  Why would I want\n>>> to commit the submodule change immediately?  Maybe I want to batch it\n>>> up with other changes and stage it at a later time.  Why should I have\n>>> to unstage them manually now?  I get the other side of the argument:\n>>> what if the user commits the .gitmodule change at a different time\n>>> from the file change?  In other words, the user should have a way of\n>>> saying 'submodule stage' and 'submodule unstage'.\n>>\n>> Hmm, AFAIK you are the first to bring up such a feature, as in most\n>> use cases doing a \"git (submodule) add <path>\" is expected to stage\n>> what you added.\n> \n> In my opinion, the 'git submodule add <path>' form is broken, because\n> it doesn't relocate the object store of the submodule repository (a\n> bug that we need to fix?).\n\nI don't think it is broken. Leaving the .git directory inside the\nsubmodule makes perfect sense for some users (e.g. those which never\nintend to push their submodule somewhere else) and doesn't do any\nharm unless you want to remove it again in the future (or need to go\nback to an older commit where the submodule directory would be in\nthe way). We have to think very hard before making such changes to\nbehavior quite some people may rely on, even though I agree some use\ncases would profit from it and I think we would do it differently if\nwe could start over again.\n\nWhat I think we need rather soonish is \"git submodule to-gitfile\",\nwhich would help your case too. We should then hint that in those\ncases where we refuse to remove a submodule when using \"git rm\" or\n\"git submodule deinit\" (or the \"git mv\" for submodules I'm currently\npreparing).\n\n>  I always use the 'git submodule add\n> <repository> <path>' form, which puts the object store of the\n> submodule repository in .git/modules of the parent repository.  This\n> form is nothing like 'git add', but more like a 'git clone': arguably,\n> 'submodule clone' is a better name for it.\n\nHmm, it does a clone first and then adds the submodule and the change\nto .gitmodules, so I still believe \"add\" is the correct term for it.\nSo I really like the color the shed currently has ;-)\n\n> Maybe the WTF \"You need to run this command from the toplevel of the\n> working tree\" needs to be fixed first?  I think it's a matter of a\n> simple pushd, popd before the operation and building the correct\n> relative path.\n\nI won't object such a change (even though I suspect it'll turn out\nmore complicated than that).\n\n>  I'm not sure how it'll work with nested submodules\n> though.  Then again, I think nested submodules are Wrong; submodules\n> are probably not the right tool for the job.\n\nHow did you come to that conclusion? Nested submodules make perfect\nsense and most people agree that in hindsight --recursive should have\nbeen the default, but again we can't simply change that now.\n\n>>> Now, for the implementation.  Do we have existing infrastructure to\n>>> stage a hunk non-interactively?  (The ability to select a hunk to\n>>> stage/ unstage programmatically).  If not, it might be quite a\n>>> non-trivial thing to write.\n>>\n>> Have fun when adding two submodules and unstage only one of them\n>> later. I think this feature will not work unless you analyze\n>> .gitmodules and stage/unstage section-wise.\n> \n> Yes, which is why I asked if we have existing infrastructure to make\n> this possible.\n\nNot that I know of.\n"},{"id":"212197","messageId":"CALkWK0kOHPrid3V5tPWBaf5eh1t7tM_oXqsQFnXugBKUGKGpUA@mail.gmail.com","threadId":"33273","inReplyTo":"7vppynxre7.fsf@alter.siamese.dyndns.org","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T18:48:53Z","receivedAt":"2013-03-25T18:48:53Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> I'm talking about slightly better defaults at the porcelain level,\n>> at most.\n>\n> If a change does not even have to break backward compatibilty, that\n> is a regular enhancement and independent from 2.0, no?\n\nOkay, I'm confused: why are you waiting for 2.0 to change push.default\nthen?  Isn't that just a \"slightly better default at the porcelain\nlevel\" and hence a \"regular enhancement\"?\n\nYou're not worried about breaking everyone's muscle memory (is that\nnot part of backward compatibility)?  So, if I understand correctly, I\ncan do changes like the following at any time (provided the reviewers\nagree that they're sane):\n1. Don't make 'git submodule add' stage (which is what this thread was\noriginally about).\n2. Set pull.autostash to true (I still have to re-roll and finish it ofcourse).\n3. Set color.ui to auto.\n4. Alias 'git status' to 'git status -sb'.\n5. Set help.autocorrect to 20.\n"},{"id":"212198","messageId":"20130325185032.GB1414@google.com","threadId":"33273","inReplyTo":"CALkWK0kOHPrid3V5tPWBaf5eh1t7tM_oXqsQFnXugBKUGKGpUA@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T18:50:32Z","receivedAt":"2013-03-25T18:50:32Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> Okay, I'm confused: why are you waiting for 2.0 to change push.default\n> then?  Isn't that just a \"slightly better default at the porcelain\n> level\" and hence a \"regular enhancement\"?\n\nNo.  Among other aspects, \"git push\" is used heavily by scripts.\n"},{"id":"212199","messageId":"CALkWK0nFVOhTjY3dfcwPvjqLZgJrENo6Ha=cv-x6io_Np8FfoA@mail.gmail.com","threadId":"33273","inReplyTo":"20130325185032.GB1414@google.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T19:06:46Z","receivedAt":"2013-03-25T19:06:46Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jonathan Nieder wrote:\n> Ramkumar Ramachandra wrote:\n>\n>> Okay, I'm confused: why are you waiting for 2.0 to change push.default\n>> then?  Isn't that just a \"slightly better default at the porcelain\n>> level\" and hence a \"regular enhancement\"?\n>\n> No.  Among other aspects, \"git push\" is used heavily by scripts.\n\nOh, I see.  I would've expected scripts to specify the refspec\nexplicitly, instead of relying on a default like this.  Then again, I\nsaw jc/push-2.0-default-to-simple -- massive changes to scripts in our\nown testsuite.\n\nThis whole \"backward compatibility\" thing is not black-or-white: it's\nshades of gray.  Can I ask about how \"backward incompatible\" the other\nsuggestions I listed were, just so I get a rough idea of your scale?\nJunio seems to be very extremist today.\n"},{"id":"212200","messageId":"20130325191356.GC1414@google.com","threadId":"33273","inReplyTo":"CALkWK0nFVOhTjY3dfcwPvjqLZgJrENo6Ha=cv-x6io_Np8FfoA@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-03-25T19:13:56Z","receivedAt":"2013-03-25T19:13:56Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n\n> This whole \"backward compatibility\" thing is not black-or-white: it's\n> shades of gray.  Can I ask about how \"backward incompatible\" the other\n> suggestions I listed were, just so I get a rough idea of your scale?\n\nIt depends on how important the change is and how painful the proposed\ntransition is.\n\nPlease don't gratuitously break things.  If there is a smooth way to\naccomplish the intended effect without much downside, that is\ngenerally preferred, even if it is harder to write the code.\n\nThere are no absolutes here.  It is about helping people in the\nreal world who never asked for such-and-such feature to avoid\nsuffering real breakage.\n\nHope that helps,\nJonathan\n"},{"id":"212204","messageId":"CALkWK0mAkabTNrBjvv4s_YfTN9j2_Aros=7ZcF7j=KAjJE-yaw@mail.gmail.com","threadId":"33273","inReplyTo":"51509ABA.3040804@web.de","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-25T19:57:18Z","receivedAt":"2013-03-25T19:57:18Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jens Lehmann wrote:\n> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:\n>> In my opinion, the 'git submodule add <path>' form is broken, because\n>> it doesn't relocate the object store of the submodule repository (a\n>> bug that we need to fix?).\n>\n> I don't think it is broken. Leaving the .git directory inside the\n> submodule makes perfect sense for some users (e.g. those which never\n> intend to push their submodule somewhere else) and doesn't do any\n> harm unless you want to remove it again in the future (or need to go\n> back to an older commit where the submodule directory would be in\n> the way). We have to think very hard before making such changes to\n> behavior quite some people may rely on, even though I agree some use\n> cases would profit from it and I think we would do it differently if\n> we could start over again.\n\nDoesn't that sound horribly crippled to you?  Is there any advantage\nto leaving the .git directory inside the submodule?  Isn't it always\nbetter to relocate it?\n\n> What I think we need rather soonish is \"git submodule to-gitfile\",\n> which would help your case too. We should then hint that in those\n> cases where we refuse to remove a submodule when using \"git rm\" or\n> \"git submodule deinit\" (or the \"git mv\" for submodules I'm currently\n> preparing).\n\nWhy a new subcommand?  Is there a problem if we do the relocation at\nthe time of 'add'?  Will some user expectation break?\n\n>>  I always use the 'git submodule add\n>> <repository> <path>' form, which puts the object store of the\n>> submodule repository in .git/modules of the parent repository.  This\n>> form is nothing like 'git add', but more like a 'git clone': arguably,\n>> 'submodule clone' is a better name for it.\n>\n> Hmm, it does a clone first and then adds the submodule and the change\n> to .gitmodules, so I still believe \"add\" is the correct term for it.\n> So I really like the color the shed currently has ;-)\n\nI meant a variant of add that would clone, but not stage.  I was\narguing for a new subcommand so that I don't have to touch 'submodule\nadd', not for a rename.\n\n>> Maybe the WTF \"You need to run this command from the toplevel of the\n>> working tree\" needs to be fixed first?  I think it's a matter of a\n>> simple pushd, popd before the operation and building the correct\n>> relative path.\n>\n> I won't object such a change (even though I suspect it'll turn out\n> more complicated than that).\n\nI'll have to investigate.\n\n>>  I'm not sure how it'll work with nested submodules\n>> though.  Then again, I think nested submodules are Wrong; submodules\n>> are probably not the right tool for the job.\n>\n> How did you come to that conclusion? Nested submodules make perfect\n> sense and most people agree that in hindsight --recursive should have\n> been the default, but again we can't simply change that now.\n\nOkay, I'll do it step-by-step now, with a live example:\n1. git clone gh:artagnon/dotfiles, a repository with submodules.\n2. git submodule update --init .elisp/auto-complete, a repository that\ncontains submodules.\n3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy,\nlib/ert, and lib/popup).  Let's try to initialize them from that\ndirectory ... No! go back to toplevel.\n4. Fine.  Where are those submodules?  git submodule status doesn't list them.\n5. Okay, let's join the paths by hand and try anyway: git submodule\nupdate --init .elisp/auto-complete/lib/fuzzy.  Did you forget to 'git\nadd'?  Fantastic.\n6. How am I supposed to initialize the darn submodules?!\n7. git submodule update --init --recursive .elisp/auto-complete is the\nONLY way (is this even documented anywhere?).  But I just wanted to\ninitialize one, not all three!\n8. Okay, now I want to execute a 'git submodule foreach' on just those\nthree submodules.  Seems impossible.  Fine, I'll do it myself: for i\nin \"lib/ert lib/fuzzy lib/popup\"; do cd $i; git checkout master; git\nreset --hard origin/master; cd ../..; done\n9. Whew.  git status.  Changes in auto-complete.  git diff.\n\"Submodule .elisp/auto-complete contains modified content\".  I'm not\nallowed to see what changed now?\n10. git checkout master; git reset --hard origin/master in\nauto-complete.  git status.  How do I stage the changes in just\nauto-complete, and not in auto-complete's submodules?  What is going\non, seriously?\n\nThis is just two levels of nesting: with more levels of nesting,\nthings only get worse.\n\n>>>> Now, for the implementation.  Do we have existing infrastructure to\n>>>> stage a hunk non-interactively?  (The ability to select a hunk to\n>>>> stage/ unstage programmatically).  If not, it might be quite a\n>>>> non-trivial thing to write.\n> [...]\n> Not that I know of.\n\nDamn.  Then, it's certainly not worth the effort.  Atleast not now,\nwhen there are bigger problems.\n"},{"id":"212247","messageId":"5150D655.8000204@web.de","threadId":"33273","inReplyTo":"CALkWK0mAkabTNrBjvv4s_YfTN9j2_Aros=7ZcF7j=KAjJE-yaw@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-03-25T22:57:25Z","receivedAt":"2013-03-25T22:57:25Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:\n> Jens Lehmann wrote:\n>> Am 25.03.2013 09:59, schrieb Ramkumar Ramachandra:\n>>> In my opinion, the 'git submodule add <path>' form is broken, because\n>>> it doesn't relocate the object store of the submodule repository (a\n>>> bug that we need to fix?).\n>>\n>> I don't think it is broken. Leaving the .git directory inside the\n>> submodule makes perfect sense for some users (e.g. those which never\n>> intend to push their submodule somewhere else) and doesn't do any\n>> harm unless you want to remove it again in the future (or need to go\n>> back to an older commit where the submodule directory would be in\n>> the way). We have to think very hard before making such changes to\n>> behavior quite some people may rely on, even though I agree some use\n>> cases would profit from it and I think we would do it differently if\n>> we could start over again.\n> \n> Doesn't that sound horribly crippled to you?  Is there any advantage\n> to leaving the .git directory inside the submodule?  Isn't it always\n> better to relocate it?\n\nIt's not crippled at all, that is just the way it was from submodule\nday one. And no, it isn't always better to relocate it. E.g. when\nyou want to be able to just tar away work tree and history someplace\nelse because you don't have (or don't want) an upstream to push to,\nyou'd be very surprised a \"submodule add\" moved your .git directory\nsomeplace else effectively nuking the backup of your history and\nrefs (guess under what circumstances you'll notice that). While I\nbelieve most submodule users would benefit from such a relocation, I\nconsider the other use cases as valid and we would introduce silent\nbreakage on them. On the other hand I made all relevant commands\ncomplain loudly about the .git directory in the submodule's work\ntree when it matters, so users can do something about it when they\nneed it and are told so.\n\nI'm not against changing that per se (we already did that for the\n\"update\" case when cloning submodules), but I'm really not convinced\nit is worth the downsides here (which it definitely was in the\n\"update\" case).\n\n>> What I think we need rather soonish is \"git submodule to-gitfile\",\n>> which would help your case too. We should then hint that in those\n>> cases where we refuse to remove a submodule when using \"git rm\" or\n>> \"git submodule deinit\" (or the \"git mv\" for submodules I'm currently\n>> preparing).\n> \n> Why a new subcommand?  Is there a problem if we do the relocation at\n> the time of 'add'?  Will some user expectation break?\n\nFor me relocation at the time of 'add' would be ok with a new option\n(and it might also make sense to have a config option changing the\ndefault for users who want that), but not as the default.\n\nAnd leaving aside 'add', there are tons of submodules out there\nwhich were cloned with older Git who have their .git directory\ninside the work tree. So a new subcommand (or at least a helper\nscript in contrib) to relocate the .git directory would really help\nhere to migrate these legacy submodules without users having to\nworry about data loss.\n\n>>>  I always use the 'git submodule add\n>>> <repository> <path>' form, which puts the object store of the\n>>> submodule repository in .git/modules of the parent repository.  This\n>>> form is nothing like 'git add', but more like a 'git clone': arguably,\n>>> 'submodule clone' is a better name for it.\n>>\n>> Hmm, it does a clone first and then adds the submodule and the change\n>> to .gitmodules, so I still believe \"add\" is the correct term for it.\n>> So I really like the color the shed currently has ;-)\n> \n> I meant a variant of add that would clone, but not stage.  I was\n> arguing for a new subcommand so that I don't have to touch 'submodule\n> add', not for a rename.\n\nAh, now I get it, I was confused by your reference to 'git submodule\nadd <repository> <path>'. I have to admit I still don't understand\nthe use case you have for adding a submodule without staging it, but\nmaybe it is just too late here.\n\n>>> Maybe the WTF \"You need to run this command from the toplevel of the\n>>> working tree\" needs to be fixed first?  I think it's a matter of a\n>>> simple pushd, popd before the operation and building the correct\n>>> relative path.\n>>\n>> I won't object such a change (even though I suspect it'll turn out\n>> more complicated than that).\n> \n> I'll have to investigate.\n\nOk, looking forward to that as I believe this would be a worthwhile\nimprovement.\n\n>>>  I'm not sure how it'll work with nested submodules\n>>> though.  Then again, I think nested submodules are Wrong; submodules\n>>> are probably not the right tool for the job.\n>>\n>> How did you come to that conclusion? Nested submodules make perfect\n>> sense and most people agree that in hindsight --recursive should have\n>> been the default, but again we can't simply change that now.\n> \n> Okay, I'll do it step-by-step now, with a live example:\n> 1. git clone gh:artagnon/dotfiles, a repository with submodules.\n> 2. git submodule update --init .elisp/auto-complete, a repository that\n> contains submodules.\n> 3. .elisp/auto-complete/.gitmodules lists the submodules (lib/fuzzy,\n> lib/ert, and lib/popup).  Let's try to initialize them from that\n> directory ... No! go back to toplevel.\n\nThat has got nothing to do with nested submodules but is the toplevel\nrequirement you already mentioned.\n\n> 4. Fine.  Where are those submodules?  git submodule status doesn't list them.\n\nDid you try 'git submodule status --recursive'? Without that option\nnested submodules won't work well at all (maybe we need a config\noption to let the user enable --recursive by default?).\n\n> 5. Okay, let's join the paths by hand and try anyway: git submodule\n> update --init .elisp/auto-complete/lib/fuzzy.  Did you forget to 'git\n> add'?  Fantastic.\n\nYou either use --recursive to include all submodules or have to cd\ninto the submodules superproject (.elisp/auto-complete here) to do\n\"git submodule update --init lib/fuzzy\".\n\n> 6. How am I supposed to initialize the darn submodules?!\n> 7. git submodule update --init --recursive .elisp/auto-complete is the\n> ONLY way (is this even documented anywhere?).  But I just wanted to\n> initialize one, not all three!\n\nThis is not the only way, see above. Patches to update submodules\nacross nested submodules are welcome.\n\n> 8. Okay, now I want to execute a 'git submodule foreach' on just those\n> three submodules.  Seems impossible.\n\nWhat about 'git submodule foreach --recursive .elisp/auto-complete'?\nOr - if that is your only populated submodule - a simple 'git\nsubmodule foreach --recursive' will do it too.\n\n> Fine, I'll do it myself: for i\n> in \"lib/ert lib/fuzzy lib/popup\"; do cd $i; git checkout master; git\n> reset --hard origin/master; cd ../..; done\n\n... and check out some arbitrary commit which most probably doesn't\nmatch what is committed in their superproject .elisp/auto-complete.\nYou asked for it ...\n\n> 9. Whew.  git status.  Changes in auto-complete.  git diff.\n> \"Submodule .elisp/auto-complete contains modified content\".  I'm not\n> allowed to see what changed now?\n\nThought about stepping into .elisp/auto-complete and doing a diff\nthere to see what is modified? What does 'git status --recursive'\nshow?\n\n> 10. git checkout master; git reset --hard origin/master in\n> auto-complete.  git status.  How do I stage the changes in just\n> auto-complete, and not in auto-complete's submodules?\n\nBy simply committing .elisp/auto-complete? Unless you record a\nsubmodule commit in its superproject, there is nothing to commit,\nright?\n\n>  What is going on, seriously?\n\nPilot error, mostly omitting the --recursive option and some\n- fixable - usability issues. Patches welcome.\n\n> This is just two levels of nesting: with more levels of nesting,\n> things only get worse.\n\nYes, you cannot have the cake and eat it. Either you incorporate\neverything into a single repo (e.g. using subtree) and loose the\nstrong distinction which content belongs to which upstream repo\n(which AFAIK is a valid choice unless you want to contribute back\nto the submodule's upstream) or you'll have to cope with the\nsubmodule borders showing up from time to time, reminding you\nwhich part of the work tree has another upstream.\n\n>>>>> Now, for the implementation.  Do we have existing infrastructure to\n>>>>> stage a hunk non-interactively?  (The ability to select a hunk to\n>>>>> stage/ unstage programmatically).  If not, it might be quite a\n>>>>> non-trivial thing to write.\n>> [...]\n>> Not that I know of.\n> \n> Damn.  Then, it's certainly not worth the effort.  Atleast not now,\n> when there are bigger problems.\n\nYep, that's what I think too.\n"},{"id":"212261","messageId":"CACsJy8BDTMmrWr9mLxo26UZ3_4Tc2uy0Dy318j+4pyZ77q4=4Q@mail.gmail.com","threadId":"33273","inReplyTo":"CALkWK0=PHNmT5zfjEaWh_5=aV7wcPdGgyCWFhjaeVrrWhL0OBw@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-03-26T03:27:32Z","receivedAt":"2013-03-26T03:27:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Mar 25, 2013 at 12:38 AM, Ramkumar Ramachandra\n<artagnon@gmail.com> wrote:\n> Git 2.0 is coming soon, so I'm excited about breaking a lot of\n> backward compatibility ;)\n\nIt's a long way to 1.39 before we jump to 2.0 ;)\n-- \nDuy\n"},{"id":"212269","messageId":"CALkWK0mXOHGJHQ85mMuoUyzti6b2QoijN1EEFzpJ+TKm3tWnXg@mail.gmail.com","threadId":"33273","inReplyTo":"5150D655.8000204@web.de","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-26T07:57:14Z","receivedAt":"2013-03-26T07:57:14Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Jens Lehmann wrote:\n> Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:\n>> Doesn't that sound horribly crippled to you?  Is there any advantage\n>> to leaving the .git directory inside the submodule?  Isn't it always\n>> better to relocate it?\n>\n> It's not crippled at all, that is just the way it was from submodule\n> day one. And no, it isn't always better to relocate it. E.g. when\n> you want to be able to just tar away work tree and history someplace\n> else because you don't have (or don't want) an upstream to push to,\n> you'd be very surprised a \"submodule add\" moved your .git directory\n> someplace else effectively nuking the backup of your history and\n> refs (guess under what circumstances you'll notice that). While I\n> believe most submodule users would benefit from such a relocation, I\n> consider the other use cases as valid and we would introduce silent\n> breakage on them. On the other hand I made all relevant commands\n> complain loudly about the .git directory in the submodule's work\n> tree when it matters, so users can do something about it when they\n> need it and are told so.\n\nI see.  Thanks for the explanation.\n\n>> Why a new subcommand?  Is there a problem if we do the relocation at\n>> the time of 'add'?  Will some user expectation break?\n>\n> For me relocation at the time of 'add' would be ok with a new option\n> (and it might also make sense to have a config option changing the\n> default for users who want that), but not as the default.\n\nMakes sense.  This seems trivial to implement: I'll get to work on it soon.\n\n> And leaving aside 'add', there are tons of submodules out there\n> which were cloned with older Git who have their .git directory\n> inside the work tree. So a new subcommand (or at least a helper\n> script in contrib) to relocate the .git directory would really help\n> here to migrate these legacy submodules without users having to\n> worry about data loss.\n\nThe question is: after using a \"non-relocated submodule\" for some\ntime, will the user suddenly decide to make it a \"relocated submodule\"\none day?\n\n>> I meant a variant of add that would clone, but not stage.  I was\n>> arguing for a new subcommand so that I don't have to touch 'submodule\n>> add', not for a rename.\n>\n> Ah, now I get it, I was confused by your reference to 'git submodule\n> add <repository> <path>'. I have to admit I still don't understand\n> the use case you have for adding a submodule without staging it, but\n> maybe it is just too late here.\n\nI usually reset after running 'git submodule add', because I rarely\ncommit the added submodule immediately after adding it.\n"},{"id":"212297","messageId":"5151D37A.6000708@web.de","threadId":"33273","inReplyTo":"CALkWK0mXOHGJHQ85mMuoUyzti6b2QoijN1EEFzpJ+TKm3tWnXg@mail.gmail.com","subject":"Re: Why does 'submodule add' stage the relevant portions?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-03-26T16:57:30Z","receivedAt":"2013-03-26T16:57:30Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.03.2013 08:57, schrieb Ramkumar Ramachandra:\n> Jens Lehmann wrote:\n>> And leaving aside 'add', there are tons of submodules out there\n>> which were cloned with older Git who have their .git directory\n>> inside the work tree. So a new subcommand (or at least a helper\n>> script in contrib) to relocate the .git directory would really help\n>> here to migrate these legacy submodules without users having to\n>> worry about data loss.\n> \n> The question is: after using a \"non-relocated submodule\" for some\n> time, will the user suddenly decide to make it a \"relocated submodule\"\n> one day?\n\nI think quite some users - and definitely myself - will do that as\nsoon as the full recursive checkout materialized, as that allows to\nremove submodules without any directory remaining and even to replace\na submodule with a directory containing other files. And even with\ncurrent Git you already get a clean work tree when using \"git rm\" or\n\"git submodule deinit\" (in current master) on a submodule iff it has\nits .git directory stored in the .git directory of the superproject.\nIt is definitely not a Must Have right now, but I expect it to be\nthat in the near future.\n\n>>> I meant a variant of add that would clone, but not stage.  I was\n>>> arguing for a new subcommand so that I don't have to touch 'submodule\n>>> add', not for a rename.\n>>\n>> Ah, now I get it, I was confused by your reference to 'git submodule\n>> add <repository> <path>'. I have to admit I still don't understand\n>> the use case you have for adding a submodule without staging it, but\n>> maybe it is just too late here.\n> \n> I usually reset after running 'git submodule add', because I rarely\n> commit the added submodule immediately after adding it.\n\nI'm not sure many submodule users do the same, but even then the\nnormal ways of unstaging the submodule and .gitmodules should be\nsufficient here, no? I'd rather avoid adding a new command to git\nsubmodule for that.\n"}]}