{"thread":{"id":"44204","subject":"Reference a submodule branch instead of a commit","startedAt":"2016-10-03T18:15:59Z","lastAt":"2016-10-05T18:22:01Z","messageCount":9,"participants":["Jeremy Morton","Junio C Hamano","Heiko Voigt","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"303105","messageId":"57F29FEF.30700@game-point.net","threadId":"44204","inReplyTo":null,"subject":"Reference a submodule branch instead of a commit","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2016-10-03T18:14:07Z","receivedAt":"2016-10-03T18:15:59Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"At the moment, supermodules must reference a given commit in each of \nits submodules. If one is in control of a submodule and it changes on \na regular basis, this can cause a lot of overhead with \"submodule \nupdated\" commits in the supermodule. It would be useful of git allows \nthe option of referencing a submodule's branch instead of a given \nsubmodule commit. How about adding this functionality?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"303106","messageId":"xmqqfuod6yw2.fsf@gitster.mtv.corp.google.com","threadId":"44204","inReplyTo":"57F29FEF.30700@game-point.net","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-03T19:00:45Z","receivedAt":"2016-10-03T19:00:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Morton writes:\n\n> At the moment, supermodules must reference a given commit in each of\n> its submodules. If one is in control of a submodule and it changes on\n> a regular basis, this can cause a lot of overhead with \"submodule\n> updated\" commits in the supermodule. It would be useful of git allows\n> the option of referencing a submodule's branch instead of a given\n> submodule commit. How about adding this functionality?\n\nWhen somebody downstream fetches from your superproject and grabs\nthe set of submodules, how would s/he know what _exact_ state you\nmeant to record? When s/he says \"I have your superproject commit X,\nwhich binds submodule's branch Y at path sub/, and it simply does\nnot work. Your project is broken\", how do you go about reproducing\nthe exact state s/he had trouble with to help her/him?\n\nThe only thing s/he knows is that the commit used from the submodule\nmust be one of the commits that was on branch Y at some point in\ntime, hopefully close to the timestamp recorded in the commit in the\nsuperproject. And your record in the history of the superproject\ndoes not tell you more than that, so you wouldn't have any idea\nbetter than what s/he already has to help.\n\nHence, such a \"functionality\" will never happen, at least in the\nexact form you are describing.\n\nIt is conceivable to add some feature that allows you to squelch the\nreport that the submodule recorded in your superproject is not up to\ndate from \"git status\" etc. to help those who thinks it is OK to not\nbind the latest submodule commit to the superproject all the time,\nthough.\n"},{"id":"303202","messageId":"20161004113625.GB20309@book.hvoigt.net","threadId":"44204","inReplyTo":"xmqqfuod6yw2.fsf@gitster.mtv.corp.google.com","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2016-10-04T11:36:26Z","receivedAt":"2016-10-04T11:36:36Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Oct 03, 2016 at 12:00:45PM -0700, Junio C Hamano wrote:\n> Jeremy Morton writes:\n> \n> > At the moment, supermodules must reference a given commit in each of\n> > its submodules. If one is in control of a submodule and it changes on\n> > a regular basis, this can cause a lot of overhead with \"submodule\n> > updated\" commits in the supermodule. It would be useful of git allows\n> > the option of referencing a submodule's branch instead of a given\n> > submodule commit. How about adding this functionality?\n> \n> When somebody downstream fetches from your superproject and grabs\n> the set of submodules, how would s/he know what _exact_ state you\n> meant to record? When s/he says \"I have your superproject commit X,\n> which binds submodule's branch Y at path sub/, and it simply does\n> not work. Your project is broken\", how do you go about reproducing\n> the exact state s/he had trouble with to help her/him?\n> \n> The only thing s/he knows is that the commit used from the submodule\n> must be one of the commits that was on branch Y at some point in\n> time, hopefully close to the timestamp recorded in the commit in the\n> superproject. And your record in the history of the superproject\n> does not tell you more than that, so you wouldn't have any idea\n> better than what s/he already has to help.\n> \n> Hence, such a \"functionality\" will never happen, at least in the\n> exact form you are describing.\n> \n> It is conceivable to add some feature that allows you to squelch the\n> report that the submodule recorded in your superproject is not up to\n> date from \"git status\" etc. to help those who thinks it is OK to not\n> bind the latest submodule commit to the superproject all the time,\n> though.\n\nWe already have options to support these kinds of workflows. Look at the\noption '--remote' for 'git submodule update'.\n\nYou then only have to commit the submodule if you do not want to see it\nas dirty locally, but you will always get the tip of a remote tracking\nbranch when updating.\n\nCheers Heiko\n"},{"id":"303258","messageId":"CAGZ79kZWtAU6YG4Qz9_Gwk2db5L2kPCCKrN+64hMYDovRjiLRw@mail.gmail.com","threadId":"44204","inReplyTo":"20161004113625.GB20309@book.hvoigt.net","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-04T17:07:09Z","receivedAt":"2016-10-04T17:07:14Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":">\n> We already have options to support these kinds of workflows. Look at the\n> option '--remote' for 'git submodule update'.\n>\n> You then only have to commit the submodule if you do not want to see it\n> as dirty locally, but you will always get the tip of a remote tracking\n> branch when updating.\n\nI wonder if we could make that convenient for users by not tracking\nthe submodule,\ni.e.\n* we have the information in the .gitmodules file\n* the path itself is in the .gitignore\n* no tree entry\n\nThen you can update to the remote latest branch, without Git reporting\na dirty submodule locally, in fact it reports nothing for the submodule.\n\nIt sounds like a hack, but maybe it's worth looking into that when\npeople want to see that workflow.\n"},{"id":"303263","messageId":"xmqqshscuilh.fsf@gitster.mtv.corp.google.com","threadId":"44204","inReplyTo":"CAGZ79kZWtAU6YG4Qz9_Gwk2db5L2kPCCKrN+64hMYDovRjiLRw@mail.gmail.com","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-04T17:31:06Z","receivedAt":"2016-10-04T17:31:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n>>\n>> We already have options to support these kinds of workflows. Look at the\n>> option '--remote' for 'git submodule update'.\n>>\n>> You then only have to commit the submodule if you do not want to see it\n>> as dirty locally, but you will always get the tip of a remote tracking\n>> branch when updating.\n>\n> I wonder if we could make that convenient for users by not tracking\n> the submodule,\n> i.e.\n> * we have the information in the .gitmodules file\n> * the path itself is in the .gitignore\n> * no tree entry\n>\n> Then you can update to the remote latest branch, without Git reporting\n> a dirty submodule locally, in fact it reports nothing for the submodule.\n>\n> It sounds like a hack, but maybe it's worth looking into that when\n> people want to see that workflow.\n\nIt IS a hack. \n\nBut if you do not touch .git file and instead say \"clone\nthis other project at that path yourself\" in README, that would\nprobably be sufficient.\n"},{"id":"303284","messageId":"xmqqlgy4szuu.fsf@gitster.mtv.corp.google.com","threadId":"44204","inReplyTo":"xmqqshscuilh.fsf@gitster.mtv.corp.google.com","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-04T19:01:13Z","receivedAt":"2016-10-04T19:01:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Stefan Beller writes:\n>\n>> I wonder if we could make that convenient for users by not tracking\n>> the submodule,\n>> i.e.\n>> * we have the information in the .gitmodules file\n>> * the path itself is in the .gitignore\n>> * no tree entry\n>>\n>> Then you can update to the remote latest branch, without Git reporting\n>> a dirty submodule locally, in fact it reports nothing for the submodule.\n>>\n>> It sounds like a hack, but maybe it's worth looking into that when\n>> people want to see that workflow.\n>\n> It IS a hack. \n>\n> But if you do not touch .git file and instead say \"clone\n> this other project at that path yourself\" in README, that would\n> probably be sufficient.\n\neh,... hit send too early.\n\nIt IS a hack, but having this information in .git would\nmean that it can be forced to be in machine readable form, unlike a\nmention in README. I do not know if the .gitmodules/.gitignore\ncombination is a sensible thing to use, but it does smell like a\npotentially useful hack.\n"},{"id":"303365","messageId":"20161005141439.GD30930@book.hvoigt.net","threadId":"44204","inReplyTo":"xmqqlgy4szuu.fsf@gitster.mtv.corp.google.com","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2016-10-05T14:14:39Z","receivedAt":"2016-10-05T14:14:51Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Oct 04, 2016 at 12:01:13PM -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Stefan Beller writes:\n> >\n> >> I wonder if we could make that convenient for users by not tracking\n> >> the submodule,\n> >> i.e.\n> >> * we have the information in the .gitmodules file\n> >> * the path itself is in the .gitignore\n> >> * no tree entry\n> >>\n> >> Then you can update to the remote latest branch, without Git reporting\n> >> a dirty submodule locally, in fact it reports nothing for the submodule.\n> >>\n> >> It sounds like a hack, but maybe it's worth looking into that when\n> >> people want to see that workflow.\n> >\n> > It IS a hack. \n> >\n> > But if you do not touch .git file and instead say \"clone\n> > this other project at that path yourself\" in README, that would\n> > probably be sufficient.\n> \n> eh,... hit send too early.\n> \n> It IS a hack, but having this information in .git would\n> mean that it can be forced to be in machine readable form, unlike a\n> mention in README. I do not know if the .gitmodules/.gitignore\n> combination is a sensible thing to use, but it does smell like a\n> potentially useful hack.\n\nIIRC the tree entries are the reference for submodules in the code. We\nare iterating over the tree entries in many places so that change does\nnot seem so easy to me.\n\nBut you are right maybe we should stop arguing against this workflow and\njust let people use it until they find out whats wrong with it ;)\n\nI have another tip for Jeremy:\n\n\tgit config submodule..ignore all\n\nand you will not see any changes to the submodule. Put that into your\n.gitmodules and you do not see any changes to the submodules anymore.\n\nSo now the only thing missing for complete convenience is a config\noption for the --remote option in 'git submodule update'.\n\nJeremy, does the ignore option combined with --remote what you want?\n\nCheers Heiko\n"},{"id":"303380","messageId":"xmqqlgy2rcxq.fsf@gitster.mtv.corp.google.com","threadId":"44204","inReplyTo":"20161005141439.GD30930@book.hvoigt.net","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-10-05T16:13:53Z","receivedAt":"2016-10-05T16:14:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n>> It IS a hack, but having this information in .git would\n>> mean that it can be forced to be in machine readable form, unlike a\n>> mention in README. I do not know if the .gitmodules/.gitignore\n>> combination is a sensible thing to use, but it does smell like a\n>> potentially useful hack.\n>\n> IIRC the tree entries are the reference for submodules in the code. We\n> are iterating over the tree entries in many places so that change does\n> not seem so easy to me.\n>\n> But you are right maybe we should stop arguing against this workflow and\n> just let people use it until they find out whats wrong with it ;)\n\nI didn't say that, though. I am fairly firm on _not_ changing what\nthe superproject records in its tree for the submodule, i.e. it must\nrecord the exact commit, not \"a branch name\", for reproducibility. \n\nI am OK if people ignored the unmatch between the recorded commit\nfrom a submodule and what they had in the submodule directory while\nthey developed and tested the superproject commit. After all, it is\nnot an error to make a commit while having a local uncommitted\nchanges to tracked files, and it is equally valid to have a commit\nchecked out in a submodule directory that is different from what\ngoes in the superproject commit. But we do show \"modified but not\ncommitted\" in the status output. In that light, submodule.*.ignore\nmay have been a mistake.\n\n"},{"id":"303418","messageId":"20161005182150.GA10927@sandbox","threadId":"44204","inReplyTo":"xmqqlgy2rcxq.fsf@gitster.mtv.corp.google.com","subject":"Re: Reference a submodule branch instead of a commit","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2016-10-05T18:21:50Z","receivedAt":"2016-10-05T18:22:01Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Oct 05, 2016 at 09:13:53AM -0700, Junio C Hamano wrote:\n> Heiko Voigt writes:\n> \n> >> It IS a hack, but having this information in .git would\n> >> mean that it can be forced to be in machine readable form, unlike a\n> >> mention in README. I do not know if the .gitmodules/.gitignore\n> >> combination is a sensible thing to use, but it does smell like a\n> >> potentially useful hack.\n> >\n> > IIRC the tree entries are the reference for submodules in the code. We\n> > are iterating over the tree entries in many places so that change does\n> > not seem so easy to me.\n> >\n> > But you are right maybe we should stop arguing against this workflow and\n> > just let people use it until they find out whats wrong with it ;)\n> \n> I didn't say that, though. I am fairly firm on _not_ changing what\n> the superproject records in its tree for the submodule, i.e. it must\n> record the exact commit, not \"a branch name\", for reproducibility. \n\nI was not talking about changing what the superproject records in its\ntree. I was just talking about changing where we look for submodules\n(e.g. for updating and such). I.e. in .git* instead of just the tree as\nit is at the moment. Thats what I understood from the discussion above.\nSorry that might have been ambiguous.\n\nI agree that there should always be a commit as a reference for a\nsubmodule. But as far as I understand for some projects its to much\noverhead to record every change of a submodule but still they want to\nuse the latest code during development. Those projects might only want\nto record the actual commit when they release something. At least thats\nwhat I imagine.\n\n> I am OK if people ignored the unmatch between the recorded commit\n> from a submodule and what they had in the submodule directory while\n> they developed and tested the superproject commit. After all, it is\n> not an error to make a commit while having a local uncommitted\n> changes to tracked files, and it is equally valid to have a commit\n> checked out in a submodule directory that is different from what\n> goes in the superproject commit. But we do show \"modified but not\n> committed\" in the status output. In that light, submodule.*.ignore\n> may have been a mistake.\n\nThe original intend for submodule.*.ignore was to help people not\nshowing submodules as dirty when they had untracked files in them. That\nwas after status learned to look into submodules. 'untracked' to avoid the\nperformance overhead and 'dirty' for the people that accidentally worked\nwith dirty submodules. I agree 'all' might have been to much.\n\nFor the above workflow what user might actually want is something that\nignores all changes as long as they are part of the remote branch. But I\nam just guessing here. My gut feeling is still that most people that\nrequest this feature come from svn. Thats why I asked whether the\noptions I described provide the behavior that Jeremy wants.\n\nCheers Heiko\n"}]}