workflow with blessed, lieutenant, and developers

workflow with blessed, lieutenant, and developers

[Mihamina Rakotomandimby]

Manao ahoana, Hello, Bonjour,
I read http://whygitisbetterthanx.com/#any-workflow.
I might not understand everything but this is what I woudl like to
implement.

I would like to setup a similar thing but with 
- Only one lieutenant (me)
- A blessed repository where I am the only one to push to
- Developers who push to me (the lieutenant)

Developers pull/clone from the blessed repository.
I initially clone from the blessed repository.

1°) What command line do developers use to push to me but not to the
blessed (origin)?
2°) After they pushed to me, I have the choice to "approve" or "reject"
a commit: what is the keyword and git option for that?
3°) I push the merge of approved commits to the blessed repository:
what keywords and git options?

Thank you for any tips :-)

Misaotra, Thanks, Merci.

-- 

       Architecte Informatique chez Blueline/Gulfsat:
    Administration Systeme, Recherche & Developpement
                                    +261 34 56 000 19

Re: workflow with blessed, lieutenant, and developers

[Joshua Juran]

On Aug 8, 2010, at 11:21 PM, Mihamina Rakotomandimby wrote:

> I would like to setup a similar thing but with
> - Only one lieutenant (me)

In Linux terminology, you would be the benevolent dictator, not the  
lieutenant.  The lieutenants are those you trust to submit good patches.

> - A blessed repository where I am the only one to push to

Okay, though I might use the term 'official'.

> - Developers who push to me (the lieutenant)

Developers shouldn't push directly into your working repo.  If you  
don't want to use pull requests (where a developer tells you when a  
branch is ready for you to pull into your own repo) then you can have  
a centralized bare Git repository for them to push to.  Either they  
will push completed branches which you then merge into mainline (which  
is essentially the same as the pull request model, except the  
developers are sharing a repo for this purpose), or the developers  
themselves will do the merging in the developer repo, which you then  
pull into your working repo, and after vetting it push to the offical  
repo.

> Developers pull/clone from the blessed repository.
> I initially clone from the blessed repository.
>
> 1°) What command line do developers use to push to me but not to the
> blessed (origin)?
> 2°) After they pushed to me, I have the choice to "approve" or  
> "reject"
> a commit: what is the keyword and git option for that?
> 3°) I push the merge of approved commits to the blessed repository:
> what keywords and git options?

If you're going to manage a project, you need to spend enough time  
learning how Git works that you can answer these questions yourself.   
There are multiple good resources online.  I suggest starting with a  
tutorial, and then experimenting to see what works and what doesn't  
before you actually try to start working for real.  Along the way  
you'll find Google very helpful.

Josh

Re: workflow with blessed, lieutenant, and developers

[Matthieu Moy]

Assuming you actually want what you want:

Mihamina Rakotomandimby <mihamina@gulfsat.mg> writes:

> 1°) What command line do developers use to push to me but not to the
> blessed (origin)?

For example:

  git remote add submission <your repository URL>

and then, submit with

  git push HEAD:submission/branch-name

> 2°) After they pushed to me, I have the choice to "approve" or "reject"
> a commit: what is the keyword and git option for that?

Actually, you have the choice between "push" and "don't push", and you
can complement the later with "git branch -D" to delete the branch.

> 3°) I push the merge of approved commits to the blessed repository:
> what keywords and git options?

What do you want that "git push" doesn't do?


Now, you may not really want this ;-). Here are some alternatives:

* Use a system like github/gitorious/giroco/gitolite, that allows you
  to manage a set of repositories with shared storage, on a single
  site. Take gitorious, for example. People would clone the blessed
  repository (like http://gitorious.org/project/repo.git) online
  (costs almost nothing thanks to shared storage). They get a remote
  repository like http://git.gitorious.org/~user/project/own-repo.git.
  Then get a local copy. They would push to
  http://git.gitorious.org/~user/project/own-repo.git, notify you of
  the changes (by email, or using gitorious itself), and you'd pull
  from them and push to the blessed repository. This way, each user
  has his own private local repository, and his submission repository.
  You avoid people messing their submission with each other.

* Look at code review tools like gerrit. I've never used them so I
  can't say much more.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: workflow with blessed, lieutenant, and developers

[Jared Hance]

On Mon, Aug 09, 2010 at 09:21:52AM +0300, Mihamina Rakotomandimby wrote:
> I would like to setup a similar thing but with 
> - Only one lieutenant (me)
> - A blessed repository where I am the only one to push to
> - Developers who push to me (the lieutenant)

There are multiple lieutenants, or none. You are the (possible
benevolent) dictator in this case.

> Developers pull/clone from the blessed repository.
> I initially clone from the blessed repository.
> 
> 1°) What command line do developers use to push to me but not to the
> blessed (origin)?

Developers don't push to someone else. They can either:
1) Send an email to the dictator requesting a pull
2) Send an email to the mailing list requesting a pull and review
3) Send patches to the mailing list requesting integration and review

I don't recomend #1 because #2 is strictly better. #3 has a specific
command: git-format-patch

When using #2/#3, its useful to have the developers CC the maintainer
of the project.

Developers usually need to push to a public branch at a hosting site
like github or repo.or.cz.

> 2°) After they pushed to me, I have the choice to "approve" or "reject"
> a commit: what is the keyword and git option for that?

Add the remote and fetch. Then merge the branch into your master (or
whatever branch you choose).

In the case of patches on a mailing list, you need to copy them to a
mailbox (for example, in Mutt, I use t to tag the group and ;C to copy
them all into a mbox) and use git-am to apply all the patches (you
should do this in a new branch). You can then choose to merge the
branch in.

> 3°) I push the merge of approved commits to the blessed repository:
> what keywords and git options?

git push origin


Make sure you remember that Git is not a replacement for
communication. There should be a way for people to review patches
BEFORE they are applied to the blessed repository.

Re: workflow with blessed, lieutenant, and developers

[Enrico Weigelt]

* Mihamina Rakotomandimby <mihamina@gulfsat.mg> wrote:

Hi,

> I would like to setup a similar thing but with 
> - Only one lieutenant (me)
> - A blessed repository where I am the only one to push to
> - Developers who push to me (the lieutenant)

if you really want them to push to you (instead of pull-requests),
you could set up an ssh-based git repo, which restricts your devs
to just their own branches (via .ssh/authorized_keys and wrapper
commands) and do whatever you like (eg. generating pull-requests,
open a ticked in some issue tracker, etc) in the post-update hook.

> 1°) What command line do developers use to push to me but not to the
> blessed (origin)?
> 2°) After they pushed to me, I have the choice to "approve" or "reject"
> a commit: what is the keyword and git option for that?
> 3°) I push the merge of approved commits to the blessed repository:
> what keywords and git options?

depends on your branch naming scheme.

man 1 git-push


you could even go some steps further and hack up wrappers/hooks
which let your dev's pushes to the main repo / mainline branch
to somewhere else (aka: masquerading). lets say your dev "Max"
pushes to master, this will actually create some new branch
"approveme/Max/$timestamp" instead of updating master itself.
now you can regularily look through these branches and decide 
whether to merge or drop them. 
(BTW: I'd recommend always rebasing to master before merging
into it - less chance of conflicts and cleaner history). 

what you need is:

a) ssh key-authentication with individual per-user commands,
   which pass the dev's pushes to intermediate/temporary
   per-user repositories. 
b) hack up an post-update hook in the intermediate repo(s),
   which push their updates into the main repo with proper
   rewritten ref names (eg. "approveme/$username/$timestamp).


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------