Re: workflow with blessed, lieutenant, and developers

[Jared Hance <jaredhance@gmail.com>]

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.