{"thread":{"id":"35478","subject":"Publishing \"filtered branch repositories\" - workflow / recommendations?","startedAt":"2013-12-04T23:01:07Z","lastAt":"2013-12-12T13:39:19Z","messageCount":13,"participants":["Martin Langhoff","Jens Lehmann","Heiko Voigt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231555","messageId":"CACPiFCJPq0fqOQrJD-8CHH405Xw61ZDynqqfN+_aZb3ZBgV2VA@mail.gmail.com","threadId":"35478","inReplyTo":null,"subject":"Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-12-04T23:01:07Z","receivedAt":"2013-12-04T23:01:07Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Hi folks.\n\ncurrently working on a project based on Moodle (the LMS that got me\ninto git in the first place). This is a highly modular software, and I\nwould like to maintain a bunch of \"out of tree\" modules in a single\nrepository, and be able to publish them in \"per-module\" repositories.\n\nSo I would like to maintain a tree with looking like\n\n auth/foomatic/{code}\n mod/foomatic/{code}\n\nwhere I can develop, branch and tag all the foomatic code together.\nYet, at release time I want to _also_ publish two repos\n\n auth-foomatic.git\n mod-foomatic.git\n\neach of them with matching tags and code at the \"root\" of the git\ntree, and ideally with a truthful history (i.e.: similar to having run\ngit filter-branch --subdirectory-filter, but able to update that\nfiltered history incrementally).\n\nIs there a reasonable approach to scripting this?\n\nAlternatively, has git submodule been improved so that it's usable by\nmere mortals (i.e.: my team), or are there strong alternatives to git\nsubmodule?\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"231621","messageId":"CACPiFCKZ4c-FgY36Y8J8OJ9E=MYxrc1BNadBF2QUWm_PD8KMLw@mail.gmail.com","threadId":"35478","inReplyTo":"CACPiFCJPq0fqOQrJD-8CHH405Xw61ZDynqqfN+_aZb3ZBgV2VA@mail.gmail.com","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-12-05T18:43:29Z","receivedAt":"2013-12-05T18:43:29Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Wed, Dec 4, 2013 at 6:01 PM, Martin Langhoff\n wrote:\n> Is there a reasonable approach to scripting this?\n\nFound my answers.\n\nThe 'subtree' merge strategy is smart enough to \"mostly\" help here.\nHowever, it does not handle new files created in the subdirectory.\n\nMy workflow is this one. It is similar to the recipes for the subtree\nmerge strategies, but invoking git mv to pull files out of the\n\ngit merge -s ours --no-commit upstream/branch\ngit read-tree --prefix= -u upstream/branch\ngit mv mysubdir/* ./ ### read-tree can't do this\ngit commit\n\n... time passes\n\ngit merge -s subtree --no-commit upstream/branch\nif [ -d mysubdir ]; then\n # handle new files\n git mv mysubdir/* ./\nfi\ngit commit\n\nglad that I ended up reading a lot about subtree.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"231625","messageId":"52A0D199.1010403@web.de","threadId":"35478","inReplyTo":"CACPiFCJPq0fqOQrJD-8CHH405Xw61ZDynqqfN+_aZb3ZBgV2VA@mail.gmail.com","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-05T19:18:49Z","receivedAt":"2013-12-05T19:18:49Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 05.12.2013 00:01, schrieb Martin Langhoff:\n> Hi folks.\n> \n> currently working on a project based on Moodle (the LMS that got me\n> into git in the first place). This is a highly modular software, and I\n> would like to maintain a bunch of \"out of tree\" modules in a single\n> repository, and be able to publish them in \"per-module\" repositories.\n> \n> So I would like to maintain a tree with looking like\n> \n> auth/foomatic/{code}\n> mod/foomatic/{code}\n> \n> where I can develop, branch and tag all the foomatic code together.\n> Yet, at release time I want to _also_ publish two repos\n> \n> auth-foomatic.git\n> mod-foomatic.git\n> \n> each of them with matching tags and code at the \"root\" of the git\n> tree, and ideally with a truthful history (i.e.: similar to having run\n> git filter-branch --subdirectory-filter, but able to update that\n> filtered history incrementally).\n> \n> Is there a reasonable approach to scripting this?\n> \n> Alternatively, has git submodule been improved so that it's usable by\n> mere mortals (i.e.: my team), or are there strong alternatives to git\n> submodule?\n\nWithout knowing more I can't think of a reason why submodules should\nnot suit your use case (but you'd have to script branching and tagging\nyourself until these commands learn to recurse into submodules too).\n\nBut maybe you'll be happier with git subtree, dunno.\n"},{"id":"231626","messageId":"CACPiFCKHprB_oO_eXMYkey_CGbT7WOn5VDDjBdHbLRzcDpHnZw@mail.gmail.com","threadId":"35478","inReplyTo":"52A0D199.1010403@web.de","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-12-05T19:27:19Z","receivedAt":"2013-12-05T19:27:19Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:\n> Without knowing more I can't think of a reason why submodules should\n> not suit your use case (but you'd have to script branching and tagging\n> yourself until these commands learn to recurse into submodules too).\n\nThe submodules feature is way too fiddly and has abundant gotchas.\n\nI am diving into subtrees, and finding it a lot more workable.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"231629","messageId":"52A0D9F5.3030101@web.de","threadId":"35478","inReplyTo":"CACPiFCKHprB_oO_eXMYkey_CGbT7WOn5VDDjBdHbLRzcDpHnZw@mail.gmail.com","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-05T19:54:29Z","receivedAt":"2013-12-05T19:54:29Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 05.12.2013 20:27, schrieb Martin Langhoff:\n> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:\n>> Without knowing more I can't think of a reason why submodules should\n>> not suit your use case (but you'd have to script branching and tagging\n>> yourself until these commands learn to recurse into submodules too).\n> \n> The submodules feature is way too fiddly and has abundant gotchas.\n\nCare to explain what bothers you the most? Being one of the people\nimproving submodules I'm really interested in hearing more about that.\n\n> I am diving into subtrees, and finding it a lot more workable.\n\nYep, for exporting parts of your repo as separate repos one way\nsubtree might be just what you want.\n"},{"id":"231641","messageId":"CACPiFCJ3mkOj=E+siideBpPfgS1tSicVQ46KqPK+Tha0DbkZHw@mail.gmail.com","threadId":"35478","inReplyTo":"52A0D9F5.3030101@web.de","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-12-05T22:06:14Z","receivedAt":"2013-12-05T22:06:14Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:\n> Am 05.12.2013 20:27, schrieb Martin Langhoff:\n>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:\n>>> Without knowing more I can't think of a reason why submodules should\n>>> not suit your use case (but you'd have to script branching and tagging\n>>> yourself until these commands learn to recurse into submodules too).\n>>\n>> The submodules feature is way too fiddly and has abundant gotchas.\n>\n> Care to explain what bothers you the most? Being one of the people\n> improving submodules I'm really interested in hearing more about that.\n\nVery glad to hear submodules is getting TLC! I have other scenarios at\n$dayjob where I may need submodules, so happy happy.\n\nI may be unaware of recent improvements, here's my (perhaps outdated) list\n\n - git clone does not clone existing submodules by default. An ideal\nworkflow assumes that the user wants a fully usable checkout.\n\n - git pull does not fetch&update all submodules (assuming a trivial\n\"tracking repos\" scenario)\n\n - git push does not warn if you forgot to push commits in the submodule\n\nthere's possibly a few others that I've forgotten. The main issue is\nthat things that are conceptually simple (clone, git pull with no\nlocal changes) are very fiddly. Our new developers, testers and\nsupport folks hurt themselves with it plenty.\n\nI don't mind complex scenarios being complex to handle. If you hit a\nnasty merge conflict in your submodule, and that's gnarly to resolve,\nthat's not a showstopper.\n\n\nWhile writing this email, I reviewed Documentation/git-submodule.txt\nin git master, and it does seem to have grown some new options. I\nwonder if there is a tutorial with an example workflow anywhere\nshowing the current level of usability. My hope is actually for some\nbits of automagic default behaviors to help things along (rather than\nnew options)...\n\nEarly git was very pedantic, and over time it learned some DWIMery.\nYou're giving me hope that similar smarts might have grown in around\nsubmodule support ...\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"231656","messageId":"52A18F69.70002@web.de","threadId":"35478","inReplyTo":"CACPiFCJ3mkOj=E+siideBpPfgS1tSicVQ46KqPK+Tha0DbkZHw@mail.gmail.com","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-06T08:48:41Z","receivedAt":"2013-12-06T08:48:41Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 05.12.2013 23:06, schrieb Martin Langhoff:\n> On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:\n>> Am 05.12.2013 20:27, schrieb Martin Langhoff:\n>>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:\n>>>> Without knowing more I can't think of a reason why submodules should\n>>>> not suit your use case (but you'd have to script branching and tagging\n>>>> yourself until these commands learn to recurse into submodules too).\n>>>\n>>> The submodules feature is way too fiddly and has abundant gotchas.\n>>\n>> Care to explain what bothers you the most? Being one of the people\n>> improving submodules I'm really interested in hearing more about that.\n> \n> Very glad to hear submodules is getting TLC! I have other scenarios at\n> $dayjob where I may need submodules, so happy happy.\n>\n> I may be unaware of recent improvements, here's my (perhaps outdated) list\n\nThanks a lot for your feedback!\n\n> - git clone does not clone existing submodules by default. An ideal\n> workflow assumes that the user wants a fully usable checkout.\n\nYou get that when using \"git clone --recurse-submodules\", but there\nis no configuration option yet to switch that on by default (but we\nare planning to add one).\n\n> - git pull does not fetch&update all submodules (assuming a trivial\n> \"tracking repos\" scenario)\n\nCurrent pull does fetch them (when changes to them are found in the\nfetched commits of the superproject), but it does not yet update\nthem (there is the \"recursive update\" work in progress to do that).\n\n> - git push does not warn if you forgot to push commits in the submodule\n\nWe do have a command line option (\"--recurse-submodules=check\" is\nwhat you want here), but no configuration option yet.\n\n> there's possibly a few others that I've forgotten. The main issue is\n> that things that are conceptually simple (clone, git pull with no\n> local changes) are very fiddly. Our new developers, testers and\n> support folks hurt themselves with it plenty.\n\nSeems like we already solved some of those, and your feedback shows\nme that we are moving in the right direction. I keep a list of open\nissues we are aware of at:\n\n https://github.com/jlehmann/git-submod-enhancements/wiki\n\nFeel free to point out missing topics.\n\n> I don't mind complex scenarios being complex to handle. If you hit a\n> nasty merge conflict in your submodule, and that's gnarly to resolve,\n> that's not a showstopper.\n\nGood to hear that! Solving them automatically is hard, only fast\nforwards are currently resolved without user intervention.\n\n> While writing this email, I reviewed Documentation/git-submodule.txt\n> in git master, and it does seem to have grown some new options. I\n> wonder if there is a tutorial with an example workflow anywhere\n> showing the current level of usability. My hope is actually for some\n> bits of automagic default behaviors to help things along (rather than\n> new options)...\n\nRight you are, we need tutorials for the most prominent use cases.\n\n> Early git was very pedantic, and over time it learned some DWIMery.\n> You're giving me hope that similar smarts might have grown in around\n> submodule support ...\n\nThat's what we are aiming at :-)\n"},{"id":"231671","messageId":"CACPiFCJ5hCPvRHB1knvMocN0XdHfSMpbZnqjf7yHAT4mMOSfzw@mail.gmail.com","threadId":"35478","inReplyTo":"52A18F69.70002@web.de","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2013-12-06T19:40:15Z","receivedAt":"2013-12-06T19:40:15Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:\n> Right you are, we need tutorials for the most prominent use cases.\n\nIn the meantime, are there any hints? Emails on this list showing a\ncurrent \"smart\" workflow? Blog posts? Notes on a wiki?\n\n>> Early git was very pedantic, and over time it learned some DWIMery.\n>> You're giving me hope that similar smarts might have grown in around\n>> submodule support ...\n>\n> That's what we are aiming at :-)\n\nThat is fantastic! Thank you.\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n - ask interesting questions\n - don't get distracted with shiny stuff - working code first\n ~ http://docs.moodle.org/en/User:Martin_Langhoff\n"},{"id":"231836","messageId":"20131209225950.GG9606@sandbox-ub","threadId":"35478","inReplyTo":"CACPiFCJ5hCPvRHB1knvMocN0XdHfSMpbZnqjf7yHAT4mMOSfzw@mail.gmail.com","subject":"Re: Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-12-09T22:59:50Z","receivedAt":"2013-12-09T22:59:50Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:\n> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:\n> > Right you are, we need tutorials for the most prominent use cases.\n> \n> In the meantime, are there any hints? Emails on this list showing a\n> current \"smart\" workflow? Blog posts? Notes on a wiki?\n\nNone that I know of mainly because we have not yet reached the goal we\nare aiming at. Maybe we should write something, A few points from\n$dayjob that come to my mind:\n\n * A submodule commit is only allowed to be merged into master in a\n superproject commit if it is merged into master (or a stable branch)\n in the submodule. That way you ensure that any submodules commits\n that are tracked in a superproject are contained in each other and\n can be cleanly merged. (no rewinds, one commit contains the other)\n\n * Submodule should be selfcontained (i.e. if its a library have tests\n that use the code you implement). That way changes in the submodule\n can be made independent from the superproject\n\n * If a submodule needs another submodule have them side by side\n instead of one inside another. See the next point for explanation.\n\n * Only one depth of recursion for submodules. Even though intuition\n tell you that if some submodule needs another it should contain the\n other its IMO not wise to do so. There will be times when some other\n submodule needs the same submodule that is contained in the other\n and then you end up with two copies of the same code. My suggestion:\n Let the superproject bundle all the dependencies between modules.\n\n * Submodules are a good solution for shared code where the dependency\n goes superproject needs submodule. If you divide code into\n submodules because of access control and the dependency is actually\n that the submodule needs the superproject it works but is less than\n optimal.\n\nThats what I can quickly suggest and probably far from complete.\n\nCheers Heiko\n"},{"id":"231843","messageId":"xmqqhaahvas2.fsf@gitster.dls.corp.google.com","threadId":"35478","inReplyTo":"20131209225950.GG9606@sandbox-ub","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-09T23:56:29Z","receivedAt":"2013-12-09T23:56:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Heiko Voigt writes:\n\n> On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:\n>> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:\n>> > Right you are, we need tutorials for the most prominent use cases.\n>> \n>> In the meantime, are there any hints? Emails on this list showing a\n>> current \"smart\" workflow? Blog posts? Notes on a wiki?\n>\n> None that I know of mainly because we have not yet reached the goal we\n> are aiming at. Maybe we should write something, A few points from\n> $dayjob that come to my mind:\n>\n> * A submodule commit is only allowed to be merged into master in a\n> superproject commit if it is merged into master (or a stable branch)\n> in the submodule. That way you ensure that any submodules commits\n> that are tracked in a superproject are contained in each other and\n> can be cleanly merged. (no rewinds, one commit contains the other)\n\nI think this is closely related to Martin's list of wishes we\nearlier saw in the thread: remind the user to push necessary\nsubmodule tip before the top-level commit that needs that commit in\nthe submodule is pushed out. Giving projects a way to implement\nsuch a policy decision would be good, and having a default policy,\nif we can find one that would be reasonable for any submodule users,\nwould be even better. Would adding a generic pre-push hook at the\ntop-level sufficient for that kind of thing, I have to wonder.\n"},{"id":"231928","messageId":"52A8E124.4000002@web.de","threadId":"35478","inReplyTo":"xmqqhaahvas2.fsf@gitster.dls.corp.google.com","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-12-11T22:03:16Z","receivedAt":"2013-12-11T22:03:16Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 10.12.2013 00:56, schrieb Junio C Hamano:\n> Heiko Voigt writes:\n> \n>> On Fri, Dec 06, 2013 at 02:40:15PM -0500, Martin Langhoff wrote:\n>>> On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote:\n>>>> Right you are, we need tutorials for the most prominent use cases.\n>>>\n>>> In the meantime, are there any hints? Emails on this list showing a\n>>> current \"smart\" workflow? Blog posts? Notes on a wiki?\n>>\n>> None that I know of mainly because we have not yet reached the goal we\n>> are aiming at. Maybe we should write something, A few points from\n>> $dayjob that come to my mind:\n>>\n>> * A submodule commit is only allowed to be merged into master in a\n>> superproject commit if it is merged into master (or a stable branch)\n>> in the submodule. That way you ensure that any submodules commits\n>> that are tracked in a superproject are contained in each other and\n>> can be cleanly merged. (no rewinds, one commit contains the other)\n> \n> I think this is closely related to Martin's list of wishes we\n> earlier saw in the thread: remind the user to push necessary\n> submodule tip before the top-level commit that needs that commit in\n> the submodule is pushed out. Giving projects a way to implement\n> such a policy decision would be good, and having a default policy,\n> if we can find one that would be reasonable for any submodule users,\n> would be even better. Would adding a generic pre-push hook at the\n> top-level sufficient for that kind of thing, I have to wonder.\n\nThat could call \"git push --dry-run --recurse-submodules=check\" to\ndeny the push if the submodule commit isn't on a remote branch. But\nthat would only work for a single hardcoded remote, as the remote\nitself does not seem to be passed to the pre-push hook.\n\nSo me thinks adding a configuration option for the --recurse-submodule\noption of push is the best way to achieve that. This could be set to\n\"check\" for those who want to push the submodule manually and to\n\"on-demand\" for those who would like to push automatically. And with\nthat option the user could configure push just like he already can do\nfor fetch and pull.\n"},{"id":"231933","messageId":"xmqqa9g7t1vb.fsf@gitster.dls.corp.google.com","threadId":"35478","inReplyTo":"52A8E124.4000002@web.de","subject":"Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-11T23:16:24Z","receivedAt":"2013-12-11T23:16:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n>> I think this is closely related to Martin's list of wishes we\n>> earlier saw in the thread: remind the user to push necessary\n>> submodule tip before the top-level commit that needs that commit in\n>> the submodule is pushed out. Giving projects a way to implement\n>> such a policy decision would be good, and having a default policy,\n>> if we can find one that would be reasonable for any submodule users,\n>> would be even better. Would adding a generic pre-push hook at the\n>> top-level sufficient for that kind of thing, I have to wonder.\n>\n> That could call \"git push --dry-run --recurse-submodules=check\" to\n> deny the push if the submodule commit isn't on a remote branch.\n> that would only work for a single hardcoded remote, as the remote\n> itself does not seem to be passed to the pre-push hook.\n>\n> So me thinks adding a configuration option for the --recurse-submodule\n> option of push is the best way to achieve that. This could be set to\n> \"check\" ...\n\nYes, that uses only a single hard-coded decision, and making the\nbranch name or remote name customizable is not enough, as you are\nstill hardcoding \"if ... isn't on\" part. It is not far-fetched to\nimagine a project wants to add more restrictions to what commit in\nthe submodule history can be bound to a tree of a published commit\nin the top-level project (e.g. \"must be a tagged release point\",\n\"must be older at least by more than two weeks\", \"must be signed by\none of these developers' keys\", etc.).\n\nSo I am not yet convinced that a simple \"option\" that supplies a few\nparameters to a single hard-coded policy is sufficient in the long\nrun.\n"},{"id":"231943","messageId":"20131212133919.GB6183@t2784.greatnet.de","threadId":"35478","inReplyTo":"xmqqa9g7t1vb.fsf@gitster.dls.corp.google.com","subject":"Re: Re: Publishing \"filtered branch repositories\" - workflow / recommendations?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2013-12-12T13:39:19Z","receivedAt":"2013-12-12T13:39:19Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Dec 11, 2013 at 03:16:24PM -0800, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> \n> >> I think this is closely related to Martin's list of wishes we\n> >> earlier saw in the thread: remind the user to push necessary\n> >> submodule tip before the top-level commit that needs that commit in\n> >> the submodule is pushed out. Giving projects a way to implement\n> >> such a policy decision would be good, and having a default policy,\n> >> if we can find one that would be reasonable for any submodule users,\n> >> would be even better. Would adding a generic pre-push hook at the\n> >> top-level sufficient for that kind of thing, I have to wonder.\n> >\n> > That could call \"git push --dry-run --recurse-submodules=check\" to\n> > deny the push if the submodule commit isn't on a remote branch.\n> > that would only work for a single hardcoded remote, as the remote\n> > itself does not seem to be passed to the pre-push hook.\n> >\n> > So me thinks adding a configuration option for the --recurse-submodule\n> > option of push is the best way to achieve that. This could be set to\n> > \"check\" ...\n> \n> Yes, that uses only a single hard-coded decision, and making the\n> branch name or remote name customizable is not enough, as you are\n> still hardcoding \"if ... isn't on\" part. It is not far-fetched to\n> imagine a project wants to add more restrictions to what commit in\n> the submodule history can be bound to a tree of a published commit\n> in the top-level project (e.g. \"must be a tagged release point\",\n> \"must be older at least by more than two weeks\", \"must be signed by\n> one of these developers' keys\", etc.).\n> \n> So I am not yet convinced that a simple \"option\" that supplies a few\n> parameters to a single hard-coded policy is sufficient in the long\n> run.\n\nWell, for the implementation of --recurse-submodules=check on push we\ntried to be as dumb as possible and just try to find out whether the\ncommit is on any remote. The reason is that when someone works on a\nbranch and pushes it for demonstration/backup/before holiday the most\ncommon mistake is that he forgets to push the submodule when pushing the\nsuperproject. So \"some remote\" seems to be the most common denominator\nfor push here. At least its better than no check at all.\n\nFor extended rules that answer questions like: \"When am I allowed to\nmerge in master?\" we need some kind of workflow definition from which we\ncan deduct such rules. A pre-push hook would allow to define rules but\nhow about an approach that is easier for the user and can maybe guide\nhim to the correct workflow.\n\nI find workflow guidance is a general problem in git and even though we\nuse hooks at $dayjob they are not always sufficient. E.g. we enforce an\n\"all commits have to be reviewed first before they enter master\" policy\nwhich is correct in most situations. But for more lightweight projects I\nwould like to loosen this rule. The problem relies in the automatic\ndistribution of hooks or options for them by project instead of by\ninstallation.\n\nOne idea: We could distribute a default set of enabled hooks that\nimplement several typical workflow options which can then be enabled by\nsimply choosing one option. The configuration should be distributeable\nvia the project e.g. a .githookconfig or .gitworkflowconfig ?\n\nThe git tools could then adapt their defaults depending on such a\nworkflow definition. But it also means we would first have to collect\nand define some typical workflows.\n\nWhat do others think? There probably have been other ideas about\nworkflow definitions already, no?\n\nCheers Heiko\n"}]}