workflow with blessed, lieutenant, and developers

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.

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

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

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

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.

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

Assuming you actually want what you want:

Mihamina Rakotomandimby <mihamina@gulfsat.mg> writes:

For example:

  git remote add submission <your repository URL>

and then, submit with

  git push HEAD:submission/branch-name

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.

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.

On Mon, Aug 09, 2010 at 09:21:52AM +0300, Mihamina Rakotomandimby wrote:

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

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.

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.

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.

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

Hi,

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.

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