Rich Freeman: > > This is one of the blockers. We haven't actually decided how we want > to use git. >
There are IMO 3 main things to consider for a git workflow: * commit policy * branching model * remote model (and history format somewhere implicitly) Deciding on a _commit policy_ should be fairly straightforward and we already have one point * gpg sign every commit (unless it's a merged branch, then we only care about the merge commit) More things to consider for commit policy are: * commit message format (line length, maybe prepend category/PN?) * do we expect repoman to run successfully for every commit (I'd say no)? * additional information that must be provided * when to force/avoid merge commits Deciding on _branching model_ should be pretty easy here too. We are mainly working on master and there may be developer-specific branches etc. History does not need to be linear. Creating additional branches is up to developers and there are no specific rules about that. The _remote model_ is: use a central repository with every developer having push access. I think this is pretty reasonable for our use case, although I'd love to see a linux-like workflow with enforced reviews that propagate through project members/leads. But I'm not sure we need that much overhead, except for non-trivial stuff like eclasses where we already require reviews (well, more or less). The only hard part is that people have to know the differences between merging/rebasing, fast-forward merges, non-fast-forward merges etc. and when and when not to do them. 'git rebase' is a powerful thing, but also pretty good to mess up your local history if used wrong. I think we can write up a gentoo-specific guide in 2-3 weeks.
