{"thread":{"id":"24676","subject":"workflow with blessed, lieutenant, and developers","startedAt":"2010-08-09T06:21:52Z","lastAt":"2010-08-13T16:47:36Z","messageCount":5,"participants":["Mihamina Rakotomandimby","Joshua Juran","Matthieu Moy","Jared Hance","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147484","messageId":"20100809092152.5f32646a@packard.rktmb.org","threadId":"24676","inReplyTo":null,"subject":"workflow with blessed, lieutenant, and developers","fromName":"Mihamina Rakotomandimby","fromEmail":"mihamina@gulfsat.mg","sentAt":"2010-08-09T06:21:52Z","receivedAt":"2010-08-09T06:21:52Z","isPatch":false,"sender":{"key":"mihamina@gulfsat.mg","avatar":null},"body":"Manao ahoana, Hello, Bonjour,\nI read http://whygitisbetterthanx.com/#any-workflow.\nI might not understand everything but this is what I woudl like to\nimplement.\n\nI would like to setup a similar thing but with \n- Only one lieutenant (me)\n- A blessed repository where I am the only one to push to\n- Developers who push to me (the lieutenant)\n\nDevelopers pull/clone from the blessed repository.\nI initially clone from the blessed repository.\n\n1°) What command line do developers use to push to me but not to the\nblessed (origin)?\n2°) After they pushed to me, I have the choice to \"approve\" or \"reject\"\na commit: what is the keyword and git option for that?\n3°) I push the merge of approved commits to the blessed repository:\nwhat keywords and git options?\n\nThank you for any tips :-)\n\nMisaotra, Thanks, Merci.\n\n-- \n\n       Architecte Informatique chez Blueline/Gulfsat:\n    Administration Systeme, Recherche & Developpement\n                                    +261 34 56 000 19\n"},{"id":"147485","messageId":"172AD488-0169-440A-89FB-DD78584D244A@gmail.com","threadId":"24676","inReplyTo":"20100809092152.5f32646a@packard.rktmb.org","subject":"Re: workflow with blessed, lieutenant, and developers","fromName":"Joshua Juran","fromEmail":"jjuran@gmail.com","sentAt":"2010-08-09T07:42:16Z","receivedAt":"2010-08-09T07:42:16Z","isPatch":false,"sender":{"key":"jjuran@gmail.com","avatar":null},"body":"On Aug 8, 2010, at 11:21 PM, Mihamina Rakotomandimby wrote:\n\n> I would like to setup a similar thing but with\n> - Only one lieutenant (me)\n\nIn Linux terminology, you would be the benevolent dictator, not the  \nlieutenant.  The lieutenants are those you trust to submit good patches.\n\n> - A blessed repository where I am the only one to push to\n\nOkay, though I might use the term 'official'.\n\n> - Developers who push to me (the lieutenant)\n\nDevelopers shouldn't push directly into your working repo.  If you  \ndon't want to use pull requests (where a developer tells you when a  \nbranch is ready for you to pull into your own repo) then you can have  \na centralized bare Git repository for them to push to.  Either they  \nwill push completed branches which you then merge into mainline (which  \nis essentially the same as the pull request model, except the  \ndevelopers are sharing a repo for this purpose), or the developers  \nthemselves will do the merging in the developer repo, which you then  \npull into your working repo, and after vetting it push to the offical  \nrepo.\n\n> Developers pull/clone from the blessed repository.\n> I initially clone from the blessed repository.\n>\n> 1°) What command line do developers use to push to me but not to the\n> blessed (origin)?\n> 2°) After they pushed to me, I have the choice to \"approve\" or  \n> \"reject\"\n> a commit: what is the keyword and git option for that?\n> 3°) I push the merge of approved commits to the blessed repository:\n> what keywords and git options?\n\nIf you're going to manage a project, you need to spend enough time  \nlearning how Git works that you can answer these questions yourself.   \nThere are multiple good resources online.  I suggest starting with a  \ntutorial, and then experimenting to see what works and what doesn't  \nbefore you actually try to start working for real.  Along the way  \nyou'll find Google very helpful.\n\nJosh\n"},{"id":"147488","messageId":"vpqr5i8dxqh.fsf@bauges.imag.fr","threadId":"24676","inReplyTo":"20100809092152.5f32646a@packard.rktmb.org","subject":"Re: workflow with blessed, lieutenant, and developers","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-08-09T07:57:42Z","receivedAt":"2010-08-09T07:57:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Assuming you actually want what you want:\n\nMihamina Rakotomandimby <mihamina@gulfsat.mg> writes:\n\n> 1°) What command line do developers use to push to me but not to the\n> blessed (origin)?\n\nFor example:\n\n  git remote add submission <your repository URL>\n\nand then, submit with\n\n  git push HEAD:submission/branch-name\n\n> 2°) After they pushed to me, I have the choice to \"approve\" or \"reject\"\n> a commit: what is the keyword and git option for that?\n\nActually, you have the choice between \"push\" and \"don't push\", and you\ncan complement the later with \"git branch -D\" to delete the branch.\n\n> 3°) I push the merge of approved commits to the blessed repository:\n> what keywords and git options?\n\nWhat do you want that \"git push\" doesn't do?\n\n\nNow, you may not really want this ;-). Here are some alternatives:\n\n* Use a system like github/gitorious/giroco/gitolite, that allows you\n  to manage a set of repositories with shared storage, on a single\n  site. Take gitorious, for example. People would clone the blessed\n  repository (like http://gitorious.org/project/repo.git) online\n  (costs almost nothing thanks to shared storage). They get a remote\n  repository like http://git.gitorious.org/~user/project/own-repo.git.\n  Then get a local copy. They would push to\n  http://git.gitorious.org/~user/project/own-repo.git, notify you of\n  the changes (by email, or using gitorious itself), and you'd pull\n  from them and push to the blessed repository. This way, each user\n  has his own private local repository, and his submission repository.\n  You avoid people messing their submission with each other.\n\n* Look at code review tools like gerrit. I've never used them so I\n  can't say much more.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"147535","messageId":"20100809193009.GA8191@localhost.localdomain","threadId":"24676","inReplyTo":"20100809092152.5f32646a@packard.rktmb.org","subject":"Re: workflow with blessed, lieutenant, and developers","fromName":"Jared Hance","fromEmail":"jaredhance@gmail.com","sentAt":"2010-08-09T19:30:09Z","receivedAt":"2010-08-09T19:30:09Z","isPatch":false,"sender":{"key":"jaredhance@gmail.com","avatar":"https://avatars.githubusercontent.com/u/170192?v=4"},"body":"On Mon, Aug 09, 2010 at 09:21:52AM +0300, Mihamina Rakotomandimby wrote:\n> I would like to setup a similar thing but with \n> - Only one lieutenant (me)\n> - A blessed repository where I am the only one to push to\n> - Developers who push to me (the lieutenant)\n\nThere are multiple lieutenants, or none. You are the (possible\nbenevolent) dictator in this case.\n\n> Developers pull/clone from the blessed repository.\n> I initially clone from the blessed repository.\n> \n> 1°) What command line do developers use to push to me but not to the\n> blessed (origin)?\n\nDevelopers don't push to someone else. They can either:\n1) Send an email to the dictator requesting a pull\n2) Send an email to the mailing list requesting a pull and review\n3) Send patches to the mailing list requesting integration and review\n\nI don't recomend #1 because #2 is strictly better. #3 has a specific\ncommand: git-format-patch\n\nWhen using #2/#3, its useful to have the developers CC the maintainer\nof the project.\n\nDevelopers usually need to push to a public branch at a hosting site\nlike github or repo.or.cz.\n\n> 2°) After they pushed to me, I have the choice to \"approve\" or \"reject\"\n> a commit: what is the keyword and git option for that?\n\nAdd the remote and fetch. Then merge the branch into your master (or\nwhatever branch you choose).\n\nIn the case of patches on a mailing list, you need to copy them to a\nmailbox (for example, in Mutt, I use t to tag the group and ;C to copy\nthem all into a mbox) and use git-am to apply all the patches (you\nshould do this in a new branch). You can then choose to merge the\nbranch in.\n\n> 3°) I push the merge of approved commits to the blessed repository:\n> what keywords and git options?\n\ngit push origin\n\n\nMake sure you remember that Git is not a replacement for\ncommunication. There should be a way for people to review patches\nBEFORE they are applied to the blessed repository.\n"},{"id":"148004","messageId":"20100813164736.GA27540@nibiru.local","threadId":"24676","inReplyTo":"20100809092152.5f32646a@packard.rktmb.org","subject":"Re: workflow with blessed, lieutenant, and developers","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-08-13T16:47:36Z","receivedAt":"2010-08-13T16:47:36Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Mihamina Rakotomandimby <mihamina@gulfsat.mg> wrote:\n\nHi,\n\n> I would like to setup a similar thing but with \n> - Only one lieutenant (me)\n> - A blessed repository where I am the only one to push to\n> - Developers who push to me (the lieutenant)\n\nif you really want them to push to you (instead of pull-requests),\nyou could set up an ssh-based git repo, which restricts your devs\nto just their own branches (via .ssh/authorized_keys and wrapper\ncommands) and do whatever you like (eg. generating pull-requests,\nopen a ticked in some issue tracker, etc) in the post-update hook.\n\n> 1°) What command line do developers use to push to me but not to the\n> blessed (origin)?\n> 2°) After they pushed to me, I have the choice to \"approve\" or \"reject\"\n> a commit: what is the keyword and git option for that?\n> 3°) I push the merge of approved commits to the blessed repository:\n> what keywords and git options?\n\ndepends on your branch naming scheme.\n\nman 1 git-push\n\n\nyou could even go some steps further and hack up wrappers/hooks\nwhich let your dev's pushes to the main repo / mainline branch\nto somewhere else (aka: masquerading). lets say your dev \"Max\"\npushes to master, this will actually create some new branch\n\"approveme/Max/$timestamp\" instead of updating master itself.\nnow you can regularily look through these branches and decide \nwhether to merge or drop them. \n(BTW: I'd recommend always rebasing to master before merging\ninto it - less chance of conflicts and cleaner history). \n\nwhat you need is:\n\na) ssh key-authentication with individual per-user commands,\n   which pass the dev's pushes to intermediate/temporary\n   per-user repositories. \nb) hack up an post-update hook in the intermediate repo(s),\n   which push their updates into the main repo with proper\n   rewritten ref names (eg. \"approveme/$username/$timestamp).\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone:  +49 36207 519931  email: weigelt@metux.de\n mobile: +49 151 27565287  icq:   210169427         skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"}]}