{"thread":{"id":"29047","subject":"Auto update submodules after merge and reset","startedAt":"2011-11-30T00:55:09Z","lastAt":"2011-12-14T15:16:39Z","messageCount":18,"participants":["Max Krasnyansky","Jens Lehmann","Andreas T.Auer","andreas.t.auer_gtml_37453@ursus.ath.cx","Phil Hord","Marc Branchaud"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180126","messageId":"4ED57EED.4040705@qualcomm.com","threadId":"29047","inReplyTo":null,"subject":"Auto update submodules after merge and reset","fromName":"Max Krasnyansky","fromEmail":"maxk@qualcomm.com","sentAt":"2011-11-30T00:55:09Z","receivedAt":"2011-11-30T00:55:09Z","isPatch":false,"sender":{"key":"maxk@qualcomm.com","avatar":null},"body":"Does anyone have a pointer to a thread/discussion that explains why git \nsubmodules are not auto\nupdated when the superproject is updated (merge, reset, etc) by default?\n\nAssuming a simple and default setup where submodule update policy is set \nto \"checkout\".\nIt seems that the default and sane behavior should be to update \n(checkout) corresponding submodule\ncommit to track the superproject.\nI can't seem to find convincing explanation why it's not the case :). \nHaving to manually update\nsubmodules after pull or reset has been error prone and confusing for \nthe devs I work with.\n\nI'm thinking about adding a config option that would enable automatic \nsubmodule update but wanted\nto see if there is some fundamental reason why it would not be accepted.\n\nThanx\nMax\n"},{"id":"180143","messageId":"4ED5E9D2.4060503@web.de","threadId":"29047","inReplyTo":"4ED57EED.4040705@qualcomm.com","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-11-30T08:31:14Z","receivedAt":"2011-11-30T08:31:14Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.11.2011 01:55, schrieb Max Krasnyansky:\n> Does anyone have a pointer to a thread/discussion that explains why git submodules are not auto\n> updated when the superproject is updated (merge, reset, etc) by default?\n\nThis is because in current git a submodules work tree gets only updated\nwhen running \"git submodule update\". A default auto update wouldn't be\nbackwards compatible (and some users really like it the way it is now).\nI'm working on a patch series to teach Git to optionally update the\nsubmodules work trees on checkout, reset merge and so on, but I'm not\nthere yet.\n\n> Assuming a simple and default setup where submodule update policy is set to \"checkout\".\n> It seems that the default and sane behavior should be to update (checkout) corresponding submodule\n> commit to track the superproject.\n\nI agree, but we should decide about a sane default when the feature is\nthere. In the first version it will be off by default, so people can make\nup their minds about breaking backwards compatibility.\n\n> I can't seem to find convincing explanation why it's not the case :). Having to manually update\n> submodules after pull or reset has been error prone and confusing for the devs I work with.\n\nYes, we even had some mis-merges because of that.\n\n> I'm thinking about adding a config option that would enable automatic submodule update but wanted\n> to see if there is some fundamental reason why it would not be accepted.\n\nI think adding something like an \"submodule.autoupdate\" config makes lots\nof sense, but IMO it should affect all work tree updating porcelain commands,\nnot just merge.\n"},{"id":"180328","messageId":"4EDD6A8C.40008@qualcomm.com","threadId":"29047","inReplyTo":"4ED5E9D2.4060503@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"Max Krasnyansky","fromEmail":"maxk@qualcomm.com","sentAt":"2011-12-06T01:06:20Z","receivedAt":"2011-12-06T01:06:20Z","isPatch":false,"sender":{"key":"maxk@qualcomm.com","avatar":null},"body":"Hi Jens,\n\nOn 11/30/2011 12:31 AM, Jens Lehmann wrote:\n> I'm working on a patch series to teach Git to optionally update the \n> submodules work trees on checkout, reset merge and so on, but I'm not \n> there yet.\n> [SNIP]\n\nSorry for not replying right away.\nEverything you suggested sounds great. We're on the same page (config \noption, etc).\nHow far along are you? Do you have a tree I could pull from to play with \nthings?\nI could help with testing, bug fixes and/or implementing parts of it. \nLet me know.\n\nFor now I implemented automatic submodules update using 'post-merge' \nhook. But obviously it does\nnot handle reset and things. I'm thinking of adding 'post-reset' and \n'pre-merge' that would be useful\nfor this and maybe other things.\n\nThanx\nMax\n"},{"id":"180412","messageId":"4EDE89D4.7040001@web.de","threadId":"29047","inReplyTo":"4EDD6A8C.40008@qualcomm.com","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-06T21:32:04Z","receivedAt":"2011-12-06T21:32:04Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 06.12.2011 02:06, schrieb Max Krasnyansky:\n> On 11/30/2011 12:31 AM, Jens Lehmann wrote:\n>> I'm working on a patch series to teach Git to optionally update the submodules work trees on checkout, reset merge and so on, but I'm not there yet.\n\n> Everything you suggested sounds great. We're on the same page (config option, etc).\n> How far along are you? Do you have a tree I could pull from to play with things?\n> I could help with testing, bug fixes and/or implementing parts of it. Let me know.\n\nGreat to hear that! Please see my GitHub repo for the current state:\nhttps://github.com/jlehmann/git-submod-enhancements\n\nIt has two interesting branches:\n\ngit-checkout-recurse-submodules:\nThis was my first attempt to tell unpack_trees() to checkout submodules\nand works quite well. Porcelain checks out submodules by default while\nplumbing learned the --recurse-submodules option to do that (and git gui\nand gitk use that option so stuff like \"Revert Changes\" does work on\nsubmodules :-). I use it at work for some time and it works quite well,\nbut doesn't handle new or deleted submodules. And unfortunately the way\nI added the flag to control submodule checkout doesn't allow to add a\nper-submodule configuration option.\n\nrecursive_submodule_checkout:\nThis is where new development happens. I added the basic infrastructure\nto have global and per-submodule configuration controlling the checkout\nand ported the unpack_trees() changes from git-checkout-recurse-submodules\nhere. I also added removal and creation of submodules based on the now\nmoved gitdir. This branch has rudimentary tests but still needs quite some\nwork.\n\nI expect to have some time around the end of year to move things forward.\nIt'd be cool if you could check the current state, after that we can\ndecide how to move the topic forward together.\n\n> For now I implemented automatic submodules update using 'post-merge' hook. But obviously it does\n> not handle reset and things. I'm thinking of adding 'post-reset' and 'pre-merge' that would be useful\n> for this and maybe other things.\n\nI doubt hooks can be more than a band aid for submodule checkout. I thought\nabout doing that too and came to the conclusion it will only handle some of\nthe issues. And you'll have to provide a real life use case to get a new\nhook accepted ;-)\n"},{"id":"180473","messageId":"jbnadt$hf8$1@dough.gmane.org","threadId":"29047","inReplyTo":"4ED5E9D2.4060503@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"Andreas T.Auer","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-07T09:07:34Z","receivedAt":"2011-12-07T09:07:34Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"Jens Lehmann wrote:\n\n> Am 30.11.2011 01:55, schrieb Max Krasnyansky:\n> I'm working on a patch series to teach Git to optionally update the\n> submodules work trees on checkout, reset merge and so on, but I'm not\n> there yet.\n>\n>> I'm thinking about adding a config option that would enable automatic\n>> submodule update but wanted to see if there is some fundamental reason\n>> why it would not be accepted.\nBecause there is no good way to do so. It would be fine when you just track \nthe submodules \"read-only\", but if you are actually working on submodules, \nit is a bad idea to always get a detached HEAD. It is also a bad idea to \nmerge or rebase on the currently checkedout branch. Because if you are \nworking on a maint branch in the submodule and then you checkout a pu branch \nin the superproject, because you have forgotten that maint branch in the \nsubmodule then all the proposed updates go to the maintenance branch -> bad. \nSo auto-update is not easy. But below I describe an idea that might solve \nthese issues and help auto-udpate to work in a sane way.\n \n> I think adding something like an \"submodule.autoupdate\" config makes lots\n> of sense, but IMO it should affect all work tree updating porcelain\n> commands, not just merge.\n\nI was thinking about submodule integration and had the idea to bind a \nsubmodule to the superproject by having special references in the submodule \nlike refs/super/master, refs/super/featureX... So these references are like \ntracking branches for the refs/heads/* of the superproject.\n\nIf you have tracking branches, the supermodule can just update the \ncorresponding branch. If this branch is currently checkedout and the work \narea is clean, then the work area is updated, too. If there is currently a \nlocal branch or a diffent super-branch checked out then the working area \nshould be considered \"detached\" from the superproject and not updated. \n\nWith this concept you could even switch branches in the superproject and the \nattached submodules follow - still having no detached HEAD. When you want to \ndo some local work on the submodule you checkout a local branch and merge \nback into the super branch later. The head of that super branch might have \nchanged by the update procedure meanwhile, but that is fine, then you just \nhave a merge instead of a fast-forward.\n\nAnother nice feature would be a recursive commit. So all changed index files \nin the _attached_ submodules would first be committed in their submodules \nand then the superproject commits too - all with one command. Currently it \nfeels a little bit like CVS - commit one file(submodule), commit the other \nfile(submodule) and then apply a label(commit the superproject) to keep the \nchanges together. \n\nIf the submodule is not attached the commit in the superproject can still \ndetect changes that have been made to the corresponding tracking branch and \npick these up.\n\nAs a summary: Tracking submodule branches in the superproject instead of \nonly the current HEAD of the submodule gives you more freedom to install \nsane auto-update procedures. Even though it will raise a lot of detailed \nquestions like \"should the refs/super/* be pushed/pulled when syncing the \nsubmodule repositories\".\n"},{"id":"180536","messageId":"4EDFE75C.5050201@web.de","threadId":"29047","inReplyTo":"jbnadt$hf8$1@dough.gmane.org","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-07T22:23:24Z","receivedAt":"2011-12-07T22:23:24Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 07.12.2011 10:07, schrieb Andreas T.Auer:\n> Jens Lehmann wrote:\n> \n>> Am 30.11.2011 01:55, schrieb Max Krasnyansky:\n>> I'm working on a patch series to teach Git to optionally update the\n>> submodules work trees on checkout, reset merge and so on, but I'm not\n>> there yet.\n>>\n>>> I'm thinking about adding a config option that would enable automatic\n>>> submodule update but wanted to see if there is some fundamental reason\n>>> why it would not be accepted.\n> Because there is no good way to do so. It would be fine when you just track \n> the submodules \"read-only\", but if you are actually working on submodules, \n> it is a bad idea to always get a detached HEAD.\n\nYMMV. We get along *really* well with this because all developers know that\nif they want to hack on a submodule, they have to create a branch in there\nfirst (and if they forget to do that, git status and friends will tell them).\nWhat bugs us is that submodule HEADs don't follow what is checked out (or\nmerged, or reset ...) in the superproject. We had some really nasty\nmismerges because of that, so we need the option to enable it.\n\n> It is also a bad idea to\n> merge or rebase on the currently checkedout branch.\n\nAs I'm no user of update=merge|rebase, I have no first hand experience on\nthat. But people do use those settings, no?\n\n> Because if you are\n> working on a maint branch in the submodule and then you checkout a pu branch \n> in the superproject, because you have forgotten that maint branch in the \n> submodule then all the proposed updates go to the maintenance branch -> bad. \n\nNope, checkout will fail and not do anything as it will detect changes in\nthe submodule to be updated by the checkout (just as it would do with a\nregular file).\n\n> So auto-update is not easy.\n\nNo, it is, and it works really well. But it might not fit your use case.\n\n> But below I describe an idea that might solve\n> these issues and help auto-udpate to work in a sane way.\n>  \n>> I think adding something like an \"submodule.autoupdate\" config makes lots\n>> of sense, but IMO it should affect all work tree updating porcelain\n>> commands, not just merge.\n> \n> I was thinking about submodule integration and had the idea to bind a \n> submodule to the superproject by having special references in the submodule \n> like refs/super/master, refs/super/featureX... So these references are like \n> tracking branches for the refs/heads/* of the superproject.\n\nHaving stuff in the submodule reference branches in the superproject\nsounds upside down, as a superproject has (and should have) zero knowledge\nabout the superproject (as it could have many different of them).\n\n> If you have tracking branches, the supermodule can just update the \n> corresponding branch. If this branch is currently checkedout and the work \n> area is clean, then the work area is updated, too. If there is currently a \n> local branch or a diffent super-branch checked out then the working area \n> should be considered \"detached\" from the superproject and not updated. \n\nThis sounds a lot like the \"follow branch tip\" model we discussed\nrecently (which could be configured via .gitmodules), but I'm not sure\nyou really are in the same boat here.\n\n> With this concept you could even switch branches in the superproject and the \n> attached submodules follow - still having no detached HEAD. When you want to \n> do some local work on the submodule you checkout a local branch and merge \n> back into the super branch later.\n\nYou lost me here. How can you merge a submodule branch into one of the\nsuperproject?\n\n> The head of that super branch might have \n> changed by the update procedure meanwhile, but that is fine, then you just \n> have a merge instead of a fast-forward.\n> \n> Another nice feature would be a recursive commit. So all changed index files \n> in the _attached_ submodules would first be committed in their submodules \n> and then the superproject commits too - all with one command. Currently it \n> feels a little bit like CVS - commit one file(submodule), commit the other \n> file(submodule) and then apply a label(commit the superproject) to keep the \n> changes together. \n> \n> If the submodule is not attached the commit in the superproject can still \n> detect changes that have been made to the corresponding tracking branch and \n> pick these up.\n> \n> As a summary: Tracking submodule branches in the superproject instead of \n> only the current HEAD of the submodule gives you more freedom to install \n> sane auto-update procedures.\n\nBut we would want to have a deterministic update procedure, no? (And what\nhas more freedom than a detached HEAD? ;-)\n\n> Even though it will raise a lot of detailed\n> questions like \"should the refs/super/* be pushed/pulled when syncing the \n> submodule repositories\".\n\nI doubt that is a good idea, as that might conflict with the same submodule\nsitting in a different superproject. But I'm interested to hear how you\nwant to solve that.\n"},{"id":"180568","messageId":"4EE07FCD.8090702@ursus.ath.cx","threadId":"29047","inReplyTo":"4EDFE75C.5050201@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-08T09:13:49Z","receivedAt":"2011-12-08T09:13:49Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"\n\nOn 07.12.2011 23:23 Jens Lehmann wrote:\n>  Am 07.12.2011 10:07, schrieb Andreas T.Auer:\n> > Jens Lehmann wrote:\n> >\n> >> Am 30.11.2011 01:55, schrieb Max Krasnyansky: I'm working on a\n> >> patch series to teach Git to optionally update the submodules\n> >> work trees on checkout, reset merge and so on, but I'm not there\n> >> yet.\n> >>\n> >>> I'm thinking about adding a config option that would enable\n> >>> automatic submodule update but wanted to see if there is some\n> >>> fundamental reason why it would not be accepted.\n> > Because there is no good way to do so. It would be fine when you\n> > just track the submodules \"read-only\", but if you are actually\n> > working on submodules, it is a bad idea to always get a detached\n> > HEAD.\n>\n>  YMMV. We get along *really* well with this because all developers\n>  know that if they want to hack on a submodule, they have to create a\n>  branch in there first (and if they forget to do that, git status and\n>  friends will tell them).\nSorry, my fault. I was answering to the question why auto-update is not \nthe default, but replied to the  wrong text block. (I should have heeded \nthe note to self about the coffee in the morning ;-) )\nHaving the config option is fine, of course. But it is not easy to \nchoose a good default auto-update method, because you need different \nworkflows for different submodules/users .\n>  What bugs us is that submodule HEADs don't follow what is checked\n>  out (or merged, or reset ...) in the superproject. We had some\n>  really nasty mismerges because of that, so we need the option to\n>  enable it.\n>\nFull ack. Using the auto-update method \"disabled\" is a bad choice, too. ;-)\n\n> > Because if you are working on a maint branch in the submodule and\n> > then you checkout a pu branch in the superproject, because you\n> > have forgotten that maint branch in the submodule then all the\n> > proposed updates go to the maintenance branch -> bad.\n>\n>  Nope, checkout will fail and not do anything as it will detect\n>  changes in the submodule to be updated by the checkout (just as it\n>  would do with a regular file).\n>\nWithout auto-update you can easily checkout the pu branch in the \nsuperproject. And when you execute\ngit submodule update --merge\nthe pu referenced commit of the submodule will be merged into the \ncurrently checkedout maint branch of the submodule without warning \nunless you have merge conflicts.\nAnd when auto-update is just running git submodule update automatically \nit would act as I described.\nBut you are right, with auto-update the submodule's HEAD can be checked \nagainst the old gitlink before it is changed. If doing it in two steps \nit is not possible to have this check.\n\n> >\n> > I was thinking about submodule integration and had the idea to\n> > bind a submodule to the superproject by having special references\n> > in the submodule like refs/super/master, refs/super/featureX... So\n> > these references are like tracking branches for the refs/heads/* of\n> > the superproject.\n>\n>  Having stuff in the submodule reference branches in the superproject\n>   sounds upside down, as a superproject has (and should have) zero\n>  knowledge about the superproject (as it could have many different of\n>  them).\n>\nMy viewpoint is that I have a big project that is divided into \nsubmodules because not all developerss need all parts of the project. \nTherefore I wanted something that uses submodules as separate repos, but \nfrom the users viewpoint it should be as if the submodules are just \nsubdirectories. It would include that diffs of submodules are not shown \nas a summary of commit messages but as a diff of the sources. And from \nthat perspective it makes more sense to have tracking branches in the \nsubmodule that are owned by the superproject. In the first thought these \ntracking refs were meant to be readonly in the submodule and only \nupdatable from the superproject, but then I thought the possibility of  \ndetaching and re-attaching is nice, too. One thing I've forgot to \nmention: the refs/super/* are not SHA1-refs to the superproject (that \nwould be stupid indeed), but they contain the corresponding gitlink-SHA1 \nfrom the revision referenced by refs/heads/*. So when you have a \ndetached HEAD after auto-update you would simply \"git checkout -B \nsuper/<superproject-branchname>\" in the submodule, with the difference \nthat it shouldn't update refs/heads/super/*, but refs/super/* so that \nthese branches can be treated specially.\n\n> > If you have tracking branches, the supermodule can just update the\n> > corresponding branch. If this branch is currently checkedout and\n> > the work area is clean, then the work area is updated, too. If\n> > there is currently a local branch or a diffent super-branch\n> > checked out then the working area should be considered \"detached\"\n> > from the superproject and not updated.\n>\n>  This sounds a lot like the \"follow branch tip\" model we discussed\n>  recently (which could be configured via .gitmodules), but I'm not\n>  sure you really are in the same boat here.\nWhen I understood that correctly it was just a configuration to what \nbranch should be automatically checked out in the submodule. This seems \nto be too complicated IMO, because when you have different branches in \nthe superproject then you may want to have different branches in the \nsubmodules, too, but you would need to configure that submodule branch \nin .gitmodules for each branch separately. I.e. in the master branch the \n.gitmodule may contain \"master\", in the maint branch the .gitmodules may \nhave \"maint\" as the branch to follow.\nI do want to follow the tip of the branch, if the superproject has that \ncurrently checked out. If the superproject checks out a tagged version \nfor a rebuild, then the submodule should not follow the tip, but should \nget a detached HEAD of the corresponding commit, just as the \nsuperproject. When the superproject goes back to the branch, the \nsubmodule should go back to its tracking branch.\n>\n> > With this concept you could even switch branches in the\n> > superproject and the attached submodules follow - still having no\n> > detached HEAD. When you want to do some local work on the\n> > submodule you checkout a local branch and merge back into the super\n> > branch later.\n>\n>  You lost me here. How can you merge a submodule branch into one of\n>  the superproject?\nIt wouldn't work, if the super/* branch would contain a superproject's \nSHA-1, that is right. But as explained above, it points to a commit of \nthe submodule.\n>\n>  But we would want to have a deterministic update procedure, no? (And\n>  what has more freedom than a detached HEAD? ;-)__\nI think my proposal would be deterministic.\nAnd everything where you can commit to has more freedom than a detached HEAD\n\n>\n> > Even though it will raise a lot of detailed questions like \"should\n> > the refs/super/* be pushed/pulled when syncing the submodule\n> > repositories\".\n>\n>  I doubt that is a good idea, as that might conflict with the same\n>  submodule sitting in a different superproject. But I'm interested to\n>  hear how you want to solve that.\nThe first answer to my question was \"yes, you need to transfer the refs \nor you get unreferenced objects\" and \"no, you can't transfer the refs, \nbecause they are owned by the superproject, not the submodule.\"\nBut binding a submodule to a superproject makes perfect sense if it is \n_one_ project that is split into submodules. In that case you only have \none superproject for a submodule and for that purpose it would be good \nworkflow. It is even nice to see which commits in the submodule belong \nto what branches in the superproject or to what release version (so \ntracking superproject tags would make sense, too). If you have a \nsubmodule that has more than one superproject but these are \nwell-defined, it could be solved using refspecs (e.g. refs/super/foo/* \nfor one and refs/super/bar/* for the other superproject), but currently \nI can't think of a context where this makes sense.\n\nOf course there are other types of submodules, so using refs/super/* \nwouldn't be a good default variant for auto-update either. E.g. if you \nuse a 3rdParty lib, then the detached HEAD is fine, because usually you \ndon't touch it except when you switch to a new version from time to time.\n"},{"id":"180732","messageId":"CABURp0rcT2FR3uOmhyPUV5W3pu7WuJzjXktmUq0eb4nOiUwDKA@mail.gmail.com","threadId":"29047","inReplyTo":"4EE07FCD.8090702@ursus.ath.cx","subject":"Re: Auto update submodules after merge and reset","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-09T23:57:18Z","receivedAt":"2011-12-09T23:57:18Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Dec 8, 2011 at 4:13 AM,  <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:\n>\n> On 07.12.2011 23:23 Jens Lehmann wrote:\n>> > If you have tracking branches, the supermodule can just update the\n>> > corresponding branch. If this branch is currently checkedout and\n>> > the work area is clean, then the work area is updated, too. If\n>> > there is currently a local branch or a diffent super-branch\n>> > checked out then the working area should be considered \"detached\"\n>> > from the superproject and not updated.\n>>\n>>  This sounds a lot like the \"follow branch tip\" model we discussed\n>>  recently (which could be configured via .gitmodules), but I'm not\n>>  sure you really are in the same boat here.\n>\n> When I understood that correctly it was just a configuration to what branch\n> should be automatically checked out in the submodule. This seems to be too\n> complicated IMO, because when you have different branches in the\n> superproject then you may want to have different branches in the submodules,\n> too, but you would need to configure that submodule branch in .gitmodules\n> for each branch separately. I.e. in the master branch the .gitmodule may\n> contain \"master\", in the maint branch the .gitmodules may have \"maint\" as\n> the branch to follow.\n\nYes, but maybe you can update this information in the .gitmodules file\neasily with a command.  Maybe it could be something simpler than \"git\nsync-gitmodules-branches\", but that is essentially what it would do:\nit would save the current branch in each submodule as the \"tracked\"\nbranch in the .gitmodules file.\n\nThe advantages to this, I think, are that\n\n1. Your \"submodule A follows branch X\" information is explicit in the\n.gitmodules file and so it is not hidden when I examine your patch.\n(It sounds to me like the refs/super/* branches would necessarily be\nhard to find since the refs/ hierarchy is usually meta data about\nlocal and remote branches.  Maybe I should think about tags and notes\nmore, though.)\n\n2. When you change to \"submodule A now follows branch Y\", this\ninformation can be unambiguously saved in the commit where it occurred\nrather than tucked away, again, in refs/super/*.\n\nThe disadvantage, maybe, are that you must now use 'git submodule\nsync' or something like that to put any .gitmodules changes into\neffect.\nOr maybe that is an advantage.  How often will this branch tracking change?\n\nI like where you are going, though.  But I have trouble following your\nmeaning when you toss around words like \"ref\" and \"HEAD\" and \"branch\"\nand \"super-branch\".  Maybe we can set up a strawman repo (virtually or\non github) where you can explain what happens now and what you wish\nwould happen instead.\n\nFor example, I have some repos like this:\n\nsuper\n   +--subA\n   +--subB\n\nI wish I could do this:\n   cd super && checkout master\n\nto get this:\n   super   (master)\n      +--subA  (master)\n      +--subB  (master)\n\nOr, if I have SubB on super/'master' tracking 'foo', I could get this:\n   super   (master)\n      +--subA  (master)\n      +--subB  (foo)\n\n\n\nAnd I wish these commands would work as if this was all one repository:\n   cd super && git diff master maint\n\n   cd super && git grep foo\n   cd subA && git grep foo -- :/\n\n   cd super && git status\n   cd subA && git status\n\nBut I wonder what this would do:\n   cd super && git remote -v &&\n   cd subA && git remote -v\n\n\n> I do want to follow the tip of the branch, if the superproject has that\n> currently checked out. If the superproject checks out a tagged version for a\n> rebuild, then the submodule should not follow the tip, but should get a\n> detached HEAD of the corresponding commit, just as the superproject. When\n> the superproject goes back to the branch, the submodule should go back to\n> its tracking branch.\n\nNow this makes sense.  I want the same thing.  I want to preserve\nhistory on \"old\" commits, but I want to \"advance to tip\" on \"new\"\ncommits.\n\nThe trouble, I think, is in telling the difference between \"old\" and\n\"new\".  I think it means there is a switch, like --auto-follow (or\n--no-auto-follow for the alternate if core.auto_follow is set).  But\nhaving a config option as the default is likely to break lots of\nscripts.\n\nSo maybe I need a new command that does this:\n    git checkout master && git submodule foreach 'git checkout master'\n\nMaybe it's called \"git checkout master --recurse-submodules\".  But I\nseem to recall this is already a non-starter for some reason, and\nanyway it doesn't solve the \"variant branches in some submodules\"\nproblem.\n\nWhich brings us back to .gitmodules.\n\n>> > With this concept you could even switch branches in the\n>> > superproject and the attached submodules follow - still having no\n>> > detached HEAD. When you want to do some local work on the\n>> > submodule you checkout a local branch and merge back into the super\n>> > branch later.\n>>\n>>  You lost me here. How can you merge a submodule branch into one of\n>>  the superproject?\n>\n> It wouldn't work, if the super/* branch would contain a superproject's\n> SHA-1, that is right. But as explained above, it points to a commit of the\n> submodule.\n>>\n>>\n>>  But we would want to have a deterministic update procedure, no? (And\n>>  what has more freedom than a detached HEAD? ;-)__\n>\n> I think my proposal would be deterministic.\n> And everything where you can commit to has more freedom than a detached HEAD\n\nYou can commit to a detached HEAD.  I do it all the time.  The trick\nis in not switching away from a detached HEAD with your local commits\nstill on it.  :-)\n\n>> > Even though it will raise a lot of detailed questions like \"should\n>> > the refs/super/* be pushed/pulled when syncing the submodule\n>> > repositories\".\n>>\n>>  I doubt that is a good idea, as that might conflict with the same\n>>  submodule sitting in a different superproject. But I'm interested to\n>>  hear how you want to solve that.\n>\n> The first answer to my question was \"yes, you need to transfer the refs or\n> you get unreferenced objects\" and \"no, you can't transfer the refs, because\n> they are owned by the superproject, not the submodule.\"\n> But binding a submodule to a superproject makes perfect sense if it is _one_\n> project that is split into submodules. In that case you only have one\n> superproject for a submodule and for that purpose it would be good workflow.\n\nThis is not useful to me, though.  Sorry.\n\n> It is even nice to see which commits in the submodule belong to what\n> branches in the superproject or to what release version (so tracking\n> superproject tags would make sense, too). If you have a submodule that has\n> more than one superproject but these are well-defined, it could be solved\n> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for the\n> other superproject), but currently I can't think of a context where this\n> makes sense.\n\nI can, but this does put the cart before the horse.  The submodule is\nsubservient to the super project in all my setups.  The submodule is\nnot aware who owns him.  He is a bit like the DAG in reverse.  He\nknows one direction only (children), not the other (parents).\n\n\nPhil\n"},{"id":"180738","messageId":"4EE2B8C3.6000906@ursus.ath.cx","threadId":"29047","inReplyTo":"CABURp0rcT2FR3uOmhyPUV5W3pu7WuJzjXktmUq0eb4nOiUwDKA@mail.gmail.com","subject":"Re: Auto update submodules after merge and reset","fromName":"Andreas T.Auer","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-10T01:41:23Z","receivedAt":"2011-12-10T01:41:23Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"\n\nOn 10.12.2011 00:57 Phil Hord wrote:\n> On Thu, Dec 8, 2011 at 4:13 AM,<andreas.t.auer_gtml_37453@ursus.ath.cx>  wrote:\n>    \n>> On 07.12.2011 23:23 Jens Lehmann wrote:\n>>      \n>>>> If you have tracking branches, the supermodule can just update the\n>>>> corresponding branch. If this branch is currently checkedout and\n>>>> the work area is clean, then the work area is updated, too. If\n>>>> there is currently a local branch or a diffent super-branch\n>>>> checked out then the working area should be considered \"detached\"\n>>>> from the superproject and not updated.\n>>>>          \n>>>   This sounds a lot like the \"follow branch tip\" model we discussed\n>>>   recently (which could be configured via .gitmodules), but I'm not\n>>>   sure you really are in the same boat here.\n>>>        \n>> When I understood that correctly it was just a configuration to what branch\n>> should be automatically checked out in the submodule. This seems to be too\n>> complicated IMO, because when you have different branches in the\n>> superproject then you may want to have different branches in the submodules,\n>> too, but you would need to configure that submodule branch in .gitmodules\n>> for each branch separately. I.e. in the master branch the .gitmodule may\n>> contain \"master\", in the maint branch the .gitmodules may have \"maint\" as\n>> the branch to follow.\n>>      \n> Yes, but maybe you can update this information in the .gitmodules file\n> easily with a command.  Maybe it could be something simpler than \"git\n> sync-gitmodules-branches\", but that is essentially what it would do:\n> it would save the current branch in each submodule as the \"tracked\"\n> branch in the .gitmodules file.\n>\n> The advantages to this, I think, are that\n>\n> 1. Your \"submodule A follows branch X\" information is explicit in the\n> .gitmodules file and so it is not hidden when I examine your patch.\n> (It sounds to me like the refs/super/* branches would necessarily be\n> hard to find since the refs/ hierarchy is usually meta data about\n> local and remote branches.  Maybe I should think about tags and notes\n> more, though.)\n>    \nBranches can be seen as \"dynamic data\" that can easily be updated, \nrenamed or even deleted, if a branch is merged into another.\nOn the other hand .gitmodules can be seen as \"static data\" because it is \ncommitted to the object database, so if you checkout an old revision, \nyou could get a version of the .gitmodules that refers to a branch, \nwhich existed at that time, but was deleted meanwhile.\n\n> 2. When you change to \"submodule A now follows branch Y\", this\n> information can be unambiguously saved in the commit where it occurred\n> rather than tucked away, again, in refs/super/*.\n>    \nIf you place a reference in refs/super/ it will be displayed by gitk \ncurrently, so it is not really hidden.\n> The disadvantage, maybe, are that you must now use 'git submodule\n> sync' or something like that to put any .gitmodules changes into\n> effect.\n> Or maybe that is an advantage.  How often will this branch tracking change?\n>    \nIt depends on your use case. In mine it will change quite often.\n> For example, I have some repos like this:\n>\n> super\n>     +--subA\n>     +--subB\n>\n> I wish I could do this:\n>     cd super&&  checkout master\n>\n> to get this:\n>     super   (master)\n>        +--subA  (master)\n>        +--subB  (master)\n>\n> Or, if I have SubB on super/'master' tracking 'foo', I could get this:\n>     super   (master)\n>        +--subA  (master)\n>        +--subB  (foo)\n>    \nNo, the branch super/master always follows the master of the \nsuperproject. That's why it is called super/, because it contains the \nbranchnames from the supermodule's namespace. The normal \"local\" \nsubmodule branches are in refs/heads/*. The references in refs/super can \neasily be created \"on the fly\" by the superproject, so they are not \nreally properties of the submodules. It is a little bit like a cookie \njar ;-).\n>    \n>> I do want to follow the tip of the branch, if the superproject has that\n>> currently checked out. If the superproject checks out a tagged version for a\n>> rebuild, then the submodule should not follow the tip, but should get a\n>> detached HEAD of the corresponding commit, just as the superproject. When\n>> the superproject goes back to the branch, the submodule should go back to\n>> its tracking branch.\n>>      \n> Now this makes sense.  I want the same thing.  I want to preserve\n> history on \"old\" commits, but I want to \"advance to tip\" on \"new\"\n> commits.\n> The trouble, I think, is in telling the difference between \"old\" and\n> \"new\".\nMy approach says: Just like the superproject. If it checks out an old \ncommit, do that, if it checks out the branch, follow.\n\n> So maybe I need a new command that does this:\n>      git checkout master&&  git submodule foreach 'git checkout master'\n>\n> Maybe it's called \"git checkout master --recurse-submodules\".  But I\n> seem to recall this is already a non-starter for some reason, and\n> anyway it doesn't solve the \"variant branches in some submodules\"\n> problem.\n>    \nI don't know that problem, but maybe it is because the master branch of \nthe submodule is not corresponding to the master branch of the \nsuperproject, which is a common use case, when external modules are used \nwith different release cycles.\nFor that reason I chose to use a different namespace in \nrefs/super/master instead of that maybe existing refs/heads/master of \nthe submodule.\n>\n> You can commit to a detached HEAD.  I do it all the time.  The trick\n> is in not switching away from a detached HEAD with your local commits\n> still on it.  :-)\n>    \nYes. And you can't push it, it can't be fetched, etc. So it really \nshouldn't be used that way, but you can do a lot of things you shouldn't \ndo in git.\n>> The first answer to my question was \"yes, you need to transfer the refs or\n>> you get unreferenced objects\" and \"no, you can't transfer the refs, because\n>> they are owned by the superproject, not the submodule.\"\n>> But binding a submodule to a superproject makes perfect sense if it is _one_\n>> project that is split into submodules. In that case you only have one\n>> superproject for a submodule and for that purpose it would be good workflow.\n>>      \n> This is not useful to me, though.  Sorry.\n>\n>    \nIt is useful in huge projects.\n>> It is even nice to see which commits in the submodule belong to what\n>> branches in the superproject or to what release version (so tracking\n>> superproject tags would make sense, too). If you have a submodule that has\n>> more than one superproject but these are well-defined, it could be solved\n>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for the\n>> other superproject), but currently I can't think of a context where this\n>> makes sense.\n>>      \n> I can, but this does put the cart before the horse.  The submodule is\n> subservient to the super project in all my setups.  The submodule is\n> not aware who owns him.  He is a bit like the DAG in reverse.  He\n> knows one direction only (children), not the other (parents).\n>\n>    \nIn the setup I have in mind, the submodules are not subservient to the \nsuperproject, but a part of the whole project.\n"},{"id":"180821","messageId":"CABURp0qmOQy0=1d7RwXMO3Bm7GwXh-60fwOKFHhyG3kDkxqxxg@mail.gmail.com","threadId":"29047","inReplyTo":"4EE2B8C3.6000906@ursus.ath.cx","subject":"Re: Auto update submodules after merge and reset","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-11T14:43:37Z","receivedAt":"2011-12-11T14:43:37Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Dec 9, 2011 at 8:41 PM, Andreas T.Auer\n<andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:\n>>> It is even nice to see which commits in the submodule belong to what\n>>> branches in the superproject or to what release version (so tracking\n>>> superproject tags would make sense, too). If you have a submodule that\n>>> has\n>>> more than one superproject but these are well-defined, it could be solved\n>>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for\n>>> the\n>>> other superproject), but currently I can't think of a context where this\n>>> makes sense.\n>>\n>> I can, but this does put the cart before the horse.  The submodule is\n>> subservient to the super project in all my setups.  The submodule is\n>> not aware who owns him.  He is a bit like the DAG in reverse.  He\n>> knows one direction only (children), not the other (parents).\n>\n> In the setup I have in mind, the submodules are not subservient to the\n> superproject, but a part of the whole project.\n\nI see that.  I have a similar project with about 20 submodules.  None\nof them are useful on their own; they are logical divisions of a large\nproject.\n\nArchitecturally, submodules are oblivious of their super-projects in\nall other respects.  Changing the architectural underpinnings should\nbe a last resort, I think.\n\nPhil\n"},{"id":"180836","messageId":"4EE51D7B.7020806@ursus.ath.cx","threadId":"29047","inReplyTo":"CABURp0rcT2FR3uOmhyPUV5W3pu7WuJzjXktmUq0eb4nOiUwDKA@mail.gmail.com","subject":"Re: Auto update submodules after merge and reset","fromName":"Andreas T.Auer","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-11T21:15:39Z","receivedAt":"2011-12-11T21:15:39Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"\n\nOn 10.12.2011 00:57 Phil Hord wrote:\n>  On Thu, Dec 8, 2011 at 4:13 AM,\n>  <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:\n>\n>  Yes, but maybe you can update this information in the .gitmodules\n>  file easily with a command.  Maybe it could be something simpler\n>  than \"git sync-gitmodules-branches\", but that is essentially what it\n>  would do: it would save the current branch in each submodule as the\n>  \"tracked\" branch in the .gitmodules file.\n\nOk, I have read a better description of the \"floating submodule\" model \nnow, so it is a different use case and somehow it makes sense. In that \ncase there are probably just a few branches that you would like to \nfollow, maybe an \"unstable\" for the newest development or \"stable\" for \nthe current release or some maintenance branches.\n\n>  Now this makes sense.  I want the same thing.  I want to preserve\n>  history on \"old\" commits, but I want to \"advance to tip\" on \"new\"\n>  commits.\n>\n>  The trouble, I think, is in telling the difference between \"old\" and\n>   \"new\".  I think it means there is a switch, like --auto-follow (or\n>  --no-auto-follow for the alternate if core.auto_follow is set).  But\n>   having a config option as the default is likely to break lots of\n>  scripts.\n\nIn my use case the branches on the submodules follow the superproject \nand (mostly) versions that are committed there, it just adds the \npossibility to keep on working without checking out a branch after an \nupdate and without colliding with existing branchnames in the submodule.\n\nThe other use case wants to follow the commits of that other submodule \nwithout checking the corresponding gitlinks into the superproject. But \nwouldn't it also make sense here to define actually a mapping in the \n.gitmodule that says \"if the branch 'develop' is checkedout in the \nsupermodule then with every submodule update automatically pull the \nnewest 'unstable' commit from the submodule\"? Or for \"master\" follow \n\"stable\" or for the \"maint\" branch follow updates in the \"bugfixes\" branch.\n\nFor example\n\n[submodule \"commonlib\"]\n     update = heads develop:unstable master:stable maint:bugfixes\n\n\nSo whenever a defined branch is checked out in the superproject the \nmapped branch will be checked out in the submodule (\"new\" commit), but \nif a (e.g. tagged) commit is checked out (\"old\" commit) then the gitlink \nin the superproject is used to check out the referenced commit in the \nsubmodule.\n\nIn http://thread.gmane.org/gmane.comp.version-control.git/183837 was \ndiscussed whether the gitlink in the superproject should be set to \nall-zero if updates follow the tip or maybe use the SHA1 of the commit \nwhen the submodule was added. I think the gitlink should be updated \neverytime when a new commit in the superproject is created.\n"},{"id":"180987","messageId":"4EE682A3.8070704@web.de","threadId":"29047","inReplyTo":"4EE51D7B.7020806@ursus.ath.cx","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-12T22:39:31Z","receivedAt":"2011-12-12T22:39:31Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n> \n> \n> On 10.12.2011 00:57 Phil Hord wrote:\n>>  On Thu, Dec 8, 2011 at 4:13 AM,\n>>  <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:\n>>\n>>  Yes, but maybe you can update this information in the .gitmodules\n>>  file easily with a command.  Maybe it could be something simpler\n>>  than \"git sync-gitmodules-branches\", but that is essentially what it\n>>  would do: it would save the current branch in each submodule as the\n>>  \"tracked\" branch in the .gitmodules file.\n> \n> Ok, I have read a better description of the \"floating submodule\" model now, so it is a different use case and somehow it makes sense. In that case there are probably just a few branches that you would like to follow, maybe an \"unstable\" for the newest development or \"stable\" for the current release or some maintenance branches.\n> \n>>  Now this makes sense.  I want the same thing.  I want to preserve\n>>  history on \"old\" commits, but I want to \"advance to tip\" on \"new\"\n>>  commits.\n>>\n>>  The trouble, I think, is in telling the difference between \"old\" and\n>>   \"new\".  I think it means there is a switch, like --auto-follow (or\n>>  --no-auto-follow for the alternate if core.auto_follow is set).  But\n>>   having a config option as the default is likely to break lots of\n>>  scripts.\n> \n> In my use case the branches on the submodules follow the superproject and (mostly) versions that are committed there, it just adds the possibility to keep on working without checking out a branch after an update and without colliding with existing branchnames in the submodule.\n\nUsing superproject branch names in the submodules make no sense for a\nlot of use cases.\n\n> The other use case wants to follow the commits of that other submodule without checking the corresponding gitlinks into the superproject. But wouldn't it also make sense here to define actually a mapping in the .gitmodule that says \"if the branch 'develop' is checkedout in the supermodule then with every submodule update automatically pull the newest 'unstable' commit from the submodule\"? Or for \"master\" follow \"stable\" or for the \"maint\" branch follow updates in the \"bugfixes\" branch.\n> \n> For example\n> \n> [submodule \"commonlib\"]\n>     update = heads develop:unstable master:stable maint:bugfixes\n\nHaving that configured with \"branch=unstable\", \"branch=stable\" etc. in\n.gitmodules on the superprojects branches would be simpler and achieve\nthe same functionality.\n\n> So whenever a defined branch is checked out in the superproject the mapped branch will be checked out in the submodule (\"new\" commit), but if a (e.g. tagged) commit is checked out (\"old\" commit) then the gitlink in the superproject is used to check out the referenced commit in the submodule.\n\nI think checkout should only use the submodule commit recorded in the\nsuperproject and a subsequent \"git submodule update\" should be needed\nto update the submodule to tip. Otherwise you record SHA-1 but still\nwon't be able to bisect ...\n\n> In http://thread.gmane.org/gmane.comp.version-control.git/183837 was discussed whether the gitlink in the superproject should be set to all-zero if updates follow the tip or maybe use the SHA1 of the commit when the submodule was added. I think the gitlink should be updated everytime when a new commit in the superproject is created.\n\nNope, only when \"git submodule update\" is run. Otherwise you'll spray the\nhistory with submodule updates totally unrelated to the commits in the\nsuperproject, which is rather confusing.\n"},{"id":"180993","messageId":"CABURp0r37+VHBVVKepHPC4jwa-wJ0b+qwLrhhFR8KXnMQYTT3w@mail.gmail.com","threadId":"29047","inReplyTo":"4EE682A3.8070704@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2011-12-12T23:43:22Z","receivedAt":"2011-12-12T23:43:22Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Dec 12, 2011 at 5:39 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n>> In http://thread.gmane.org/gmane.comp.version-control.git/183837 was discussed whether the gitlink in the superproject should be set to all-zero if updates follow the tip or maybe use the SHA1 of the commit when the submodule was added. I think the gitlink should be updated everytime when a new commit in the superproject is created.\n>\n> Nope, only when \"git submodule update\" is run. Otherwise you'll spray the\n> history with submodule updates totally unrelated to the commits in the\n> superproject, which is rather confusing.\n\n\nAnd this is why my superproject is a makefile, a .gitmodules file and\na bunch of gitlinks.  We only use it to track the advancement of\nsubmodule activity.\n\nSo yes, I want my superproject's gitlinks to update automatically.  I\njust don't know a smart way to make that happen.\n\nPhil\n"},{"id":"181026","messageId":"4EE70427.3010605@web.de","threadId":"29047","inReplyTo":"CABURp0r37+VHBVVKepHPC4jwa-wJ0b+qwLrhhFR8KXnMQYTT3w@mail.gmail.com","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-13T07:52:07Z","receivedAt":"2011-12-13T07:52:07Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 13.12.2011 00:43, schrieb Phil Hord:\n> On Mon, Dec 12, 2011 at 5:39 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>> Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n>>> In http://thread.gmane.org/gmane.comp.version-control.git/183837 was discussed whether the gitlink in the superproject should be set to all-zero if updates follow the tip or maybe use the SHA1 of the commit when the submodule was added. I think the gitlink should be updated everytime when a new commit in the superproject is created.\n>>\n>> Nope, only when \"git submodule update\" is run. Otherwise you'll spray the\n>> history with submodule updates totally unrelated to the commits in the\n>> superproject, which is rather confusing.\n> \n> And this is why my superproject is a makefile, a .gitmodules file and\n> a bunch of gitlinks.  We only use it to track the advancement of\n> submodule activity.\n\nWhich is fine. Did you think about having a branch where only the\nsubmodules are updated (and built and tested) and committed to by a\nbuildbot when everything is fine? You could then merge that branch\nwhenever you want up-to-date submodules and have the reproducibility\nof the exact model while being able to \"float\" along the updates of\nthat branch?\n\nI think it always boils down to this: Either commit new gitlinks, so\nthe submodules get updated in a reproducible manner, or don't use\ngitlinks at all so the submodules can float wherever they want.\n\n> So yes, I want my superproject's gitlinks to update automatically.  I\n> just don't know a smart way to make that happen.\n\nYup, that has been the endpoint of all discussions about that topic\nso far. And until someone comes up with a smart way to make that\nhappen, I would rather not put something half-baked into git.\n\n(But please tell us when you found a smart way to do that! ;-)\n"},{"id":"181029","messageId":"4EE71E9F.90204@ursus.ath.cx","threadId":"29047","inReplyTo":"4EE682A3.8070704@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"Andreas T.Auer","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-13T09:45:03Z","receivedAt":"2011-12-13T09:45:03Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"\n\nOn 12.12.2011 23:39 Jens Lehmann wrote:\n>  Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n> >\n> > In my use case the branches on the submodules follow the\n> > superproject and (mostly) versions that are committed there, it\n> > just adds the possibility to keep on working without checking out\n> > a branch after an update and without colliding with existing\n> > branchnames in the submodule.\n>\n>  Using superproject branch names in the submodules make no sense for a\n>  lot of use cases.\nThe most useful workflows for some use cases make no sense for a lot of \nother use cases. That is why configuration options are useful, right? \nThere is no one-size-fits-all. It surely won't make sense for \nindependent submodules.\n\n> > The other use case wants to follow the commits of that other\n> > submodule without checking the corresponding gitlinks into the\n> > superproject. But wouldn't it also make sense here to define\n> > actually a mapping in the .gitmodule that says \"if the branch\n> > 'develop' is checkedout in the supermodule then with every\n> > submodule update automatically pull the newest 'unstable' commit\n> > from the submodule\"? Or for \"master\" follow \"stable\" or for the\n> > \"maint\" branch follow updates in the \"bugfixes\" branch.\n> >\n> > For example\n> >\n> > [submodule \"commonlib\"] update = heads develop:unstable\n> > master:stable maint:bugfixes\n>\n>  Having that configured with \"branch=unstable\", \"branch=stable\" etc.\n>  in .gitmodules on the superprojects branches would be simpler and\n>  achieve the same functionality.\n\nYes, this has been my first thought also, but there is also a good point \nto keep the .gitmodules stable, or you always have to change the file \nwhen branches change their names. So when the maint branch of version \n1.3 become an archive branch and the new maint is on 1.4, which was the \nmaster before then you have to change the .gitmodules on these branches. \nI.e. .gitmodules of 1.4 have \"stable\" and must have \"bugfixes\" now and \n.gitmodules of 1.3 has \"bugfixes\" and must remove the floating \ncompletely. I'm not sure that this can always be solved with \"easy\" \nmerging and therefore it is probably not really simpler, when you have \nto do this for every new release. Or what do you think?\n\n> > So whenever a defined branch is checked out in the superproject\n> > the mapped branch will be checked out in the submodule (\"new\"\n> > commit), but if a (e.g. tagged) commit is checked out (\"old\"\n> > commit) then the gitlink in the superproject is used to check out\n> > the referenced commit in the submodule.\n>\n>  I think checkout should only use the submodule commit recorded in the\n>  superproject and a subsequent \"git submodule update\" should be needed\n>  to update the submodule to tip. Otherwise you record SHA-1 but still\n>  won't be able to bisect ...\n\nbisect would leave the branch and therefore uses the recorded SHA1 for \nthe submodule checkout instead of the tip. \"follow-the-tip\" should only \nwork if the superproject follows the tip.\nIf you configure auto-update on checkout you would not expect that a \nseparate git submodule update has a different behavior.\n\n> > In http://thread.gmane.org/gmane.comp.version-control.git/183837\n> > was discussed whether the gitlink in the superproject should be\n> > set to all-zero if updates follow the tip or maybe use the SHA1 of\n> > the commit when the submodule was added. I think the gitlink should\n> > be updated everytime when a new commit in the superproject is\n> > created.\n>\n>  Nope, only when \"git submodule update\" is run. Otherwise you'll\n>  spray the history with submodule updates totally unrelated to the\n>  commits in the superproject, which is rather confusing.\n\nOf course, committing a new version to the superproject should not \ntrigger pulling in a new version for the submodule or an automatic jump \nto the tip of the submodule. I just meant a normal manual \"commit -a\" \nbehavior. Putting a 0{40} hash in the gitlink or only the hash of the \nsubmodule, when it first was added would be a special treatment that is \nneither needed nor wanted.\n"},{"id":"181083","messageId":"4EE7C733.4010209@web.de","threadId":"29047","inReplyTo":"4EE71E9F.90204@ursus.ath.cx","subject":"Re: Auto update submodules after merge and reset","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-12-13T21:44:19Z","receivedAt":"2011-12-13T21:44:19Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 13.12.2011 10:45, schrieb Andreas T.Auer:\n> On 12.12.2011 23:39 Jens Lehmann wrote:\n>>  Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n>> > The other use case wants to follow the commits of that other\n>> > submodule without checking the corresponding gitlinks into the\n>> > superproject. But wouldn't it also make sense here to define\n>> > actually a mapping in the .gitmodule that says \"if the branch\n>> > 'develop' is checkedout in the supermodule then with every\n>> > submodule update automatically pull the newest 'unstable' commit\n>> > from the submodule\"? Or for \"master\" follow \"stable\" or for the\n>> > \"maint\" branch follow updates in the \"bugfixes\" branch.\n>> >\n>> > For example\n>> >\n>> > [submodule \"commonlib\"] update = heads develop:unstable\n>> > master:stable maint:bugfixes\n>>\n>>  Having that configured with \"branch=unstable\", \"branch=stable\" etc.\n>>  in .gitmodules on the superprojects branches would be simpler and\n>>  achieve the same functionality.\n> \n> Yes, this has been my first thought also, but there is also a good point to keep the .gitmodules stable, or you always have to change the file when branches change their names. So when the maint branch of version 1.3 become an archive branch and the new maint is on 1.4, which was the master before then you have to change the .gitmodules on these branches. I.e. .gitmodules of 1.4 have \"stable\" and must have \"bugfixes\" now and .gitmodules of 1.3 has \"bugfixes\" and must remove the floating completely. I'm not sure that this can always be solved with \"easy\" merging and therefore it is probably not really simpler, when you have to do this for every new release. Or what do you think?\n\nI never rename branches, so I do not concur ;-) And I think the\n.gitmodules file could benefit from a special merge driver being\naware of the format and some subtleties (like not just adding a\n\"branch\" setting but rather creating a merge conflict) anyways.\nSo I'd prefer to keep it simple and just use the .gitmodules we\nalready have which can be different in different branches.\n\n>> > So whenever a defined branch is checked out in the superproject\n>> > the mapped branch will be checked out in the submodule (\"new\"\n>> > commit), but if a (e.g. tagged) commit is checked out (\"old\"\n>> > commit) then the gitlink in the superproject is used to check out\n>> > the referenced commit in the submodule.\n>>\n>>  I think checkout should only use the submodule commit recorded in the\n>>  superproject and a subsequent \"git submodule update\" should be needed\n>>  to update the submodule to tip. Otherwise you record SHA-1 but still\n>>  won't be able to bisect ...\n> \n> bisect would leave the branch and therefore uses the recorded SHA1 for the submodule checkout instead of the tip. \"follow-the-tip\" should only work if the superproject follows the tip.\n\nIf you follow a tip there won't be any new SHA-1s recorded during\nthat following so you could not do a bisect and expect the submodule\nto be what the developer had when doing the commits, no?\n\n> If you configure auto-update on checkout you would not expect that a separate git submodule update has a different behavior.\n\nSure you do, when auto-update on checkout is active \"git submodule update\"\nbecomes a no-op for the exact submodule model, as \"git checkout\" will do\nall the work \"git submodule update\" did before.\n\n>> > In http://thread.gmane.org/gmane.comp.version-control.git/183837\n>> > was discussed whether the gitlink in the superproject should be\n>> > set to all-zero if updates follow the tip or maybe use the SHA1 of\n>> > the commit when the submodule was added. I think the gitlink should\n>> > be updated everytime when a new commit in the superproject is\n>> > created.\n>>\n>>  Nope, only when \"git submodule update\" is run. Otherwise you'll\n>>  spray the history with submodule updates totally unrelated to the\n>>  commits in the superproject, which is rather confusing.\n> \n> Of course, committing a new version to the superproject should not trigger pulling in a new version for the submodule or an automatic jump to the tip of the submodule. I just meant a normal manual \"commit -a\" behavior. Putting a 0{40} hash in the gitlink or only the hash of the submodule, when it first was added would be a special treatment that is neither needed nor wanted.\n\nI don't get that, what SHA-1 do you want to put into the gitlink?\nI understand that floating is not about updating the SHA-1 for the\nsubmodule each commit, right?\n"},{"id":"181089","messageId":"4EE7DA2C.7000300@ursus.ath.cx","threadId":"29047","inReplyTo":"4EE7C733.4010209@web.de","subject":"Re: Auto update submodules after merge and reset","fromName":"Andreas T.Auer","fromEmail":"andreas.t.auer_gtml_37453@ursus.ath.cx","sentAt":"2011-12-13T23:05:16Z","receivedAt":"2011-12-13T23:05:16Z","isPatch":false,"sender":{"key":"andreas.t.auer_gtml_37453@ursus.ath.cx","avatar":null},"body":"\n\nOn 13.12.2011 22:44 Jens Lehmann wrote:\n>  Am 13.12.2011 10:45, schrieb Andreas T.Auer:\n> > On 12.12.2011 23:39 Jens Lehmann wrote:\n> >> Am 11.12.2011 22:15, schrieb Andreas T.Auer:\n> >>> For example\n> >>>\n> >>> [submodule \"commonlib\"] update = heads develop:unstable\n> >>> master:stable maint:bugfixes\n> >>\n> >> Having that configured with \"branch=unstable\", \"branch=stable\"\n> >> etc. in .gitmodules on the superprojects branches would be\n> >> simpler and achieve the same functionality.\n> >\n> > Yes, this has been my first thought also, but there is also a good\n> > point to keep the .gitmodules stable, or you always have to change\n> > the file when branches change their names. So when the maint branch\n> > of version 1.3 become an archive branch and the new maint is on\n> > 1.4, which was the master before then you have to change the\n> > .gitmodules on these branches. I.e. .gitmodules of 1.4 have\n> > \"stable\" and must have \"bugfixes\" now and .gitmodules of 1.3 has\n> > \"bugfixes\" and must remove the floating completely. I'm not sure\n> > that this can always be solved with \"easy\" merging and therefore it\n> > is probably not really simpler, when you have to do this for every\n> > new release. Or what do you think?\n>\n>  I never rename branches, so I do not concur ;-)\n\nWell, maybe you don't, but Junio does something like that. There is a \nmaint-1.7.7 where maint has been before and maint jumped to master.\n\n>  And I think the .gitmodules file could benefit from a special merge\n>  driver being aware of the format and some subtleties (like not just\n>  adding a \"branch\" setting but rather creating a merge conflict)\n>  anyways.\n\nIf that would work it would be fine, but you would still have to create \na new commit, when maint jumps to master and you need to update the \n.gitmodules to be a maint .gitmodules.\n\n>  So I'd prefer to keep it simple and just use the .gitmodules we\n>  already have which can be different in different branches.\n\nI agree that the .gitmodule format would be simpler, but I'd prefer the \n.gitmodule to be a little bit more complex, but more stable.\n\n> >>> So whenever a defined branch is checked out in the\n> >>> superproject the mapped branch will be checked out in the\n> >>> submodule (\"new\" commit), but if a (e.g. tagged) commit is\n> >>> checked out (\"old\" commit) then the gitlink in the superproject\n> >>> is used to check out the referenced commit in the submodule.\n> >>\n> >> I think checkout should only use the submodule commit recorded in\n> >> the superproject and a subsequent \"git submodule update\" should\n> >> be needed to update the submodule to tip. Otherwise you record\n> >> SHA-1 but still won't be able to bisect ...\n> >\n> > bisect would leave the branch and therefore uses the recorded SHA1\n> > for the submodule checkout instead of the tip. \"follow-the-tip\"\n> > should only work if the superproject follows the tip.\n>\n>  If you follow a tip there won't be any new SHA-1s recorded during\n>  that following so you could not do a bisect and expect the submodule\n>  to be what the developer had when doing the commits, no?\n\nIf you never commit something to the superproject, you wouldn't get \nSHA1s recorded, that's right. But when you commit something to the \nsuperproject, why shouldn't the current submodule SHA1 be stored? \nFloating is about _ignoring_ the recorded SHA1 in _some_ cases, not \nabout disabling the recording. So you can bisect to the bad superproject \ncommit. If you suspect a bad submodule commit causing the problem then \nyou could still bisect the submodule commits between the recorded SHA1s.\n"},{"id":"181144","messageId":"4EE8BDD7.1080507@xiplink.com","threadId":"29047","inReplyTo":"4EE7DA2C.7000300@ursus.ath.cx","subject":"Re: Auto update submodules after merge and reset","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-12-14T15:16:39Z","receivedAt":"2011-12-14T15:16:39Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-12-13 06:05 PM, Andreas T.Auer wrote:\n> \n> On 13.12.2011 22:44 Jens Lehmann wrote:\n>>\n>>  If you follow a tip there won't be any new SHA-1s recorded during\n>>  that following so you could not do a bisect and expect the submodule\n>>  to be what the developer had when doing the commits, no?\n> \n> If you never commit something to the superproject, you wouldn't get SHA1s\n> recorded, that's right. But when you commit something to the superproject,\n> why shouldn't the current submodule SHA1 be stored? Floating is about\n> _ignoring_ the recorded SHA1 in _some_ cases, not about disabling the\n> recording. So you can bisect to the bad superproject commit. If you suspect a\n> bad submodule commit causing the problem then you could still bisect the\n> submodule commits between the recorded SHA1s.\n\nTo me this question is one of the more problematic aspects of floating\nsubmodules: When to commit submodule SHA1s.\n\nAndreas suggests always committing them whenever a submodule's tip is moved.\n I don't think this is practical because commits end up with extra changes\nthat likely have nothing to do with the commit's topic.  This makes it\ndifficult to merge (or even cherry-pick) a commit elsewhere without also\npicking up an unwanted submodule update.\n\nJens suggests never committing submodule SHA1s.  This makes it difficult to\nrestore the submodules to the state they were in when a super-repo commit was\nmade.  To me this is unacceptable -- if commits don't encompass the entire\nstate of the repo (including its submodules) then they're pretty much\nuseless.  Well, maybe commits themselves don't need to do that, but I sure\nneed some way to restore the entire state of the repo.\n\nI'm not sure there's a good or easy answer here.  I suspect that it should\nalways be up to the user whether or not submodule changes are included in a\ncommit.  The way git currently works, that means that a floating checkout\nwould always have a modified status when in fact it isn't really dirty but\nmerely smudged.\n\nWish I could propose a solution, but all I have are questions!\n\n\t\tM.\n"}]}