What is our preferred gitorious workflow wrt merges and pushes?

[Andreas Pakulat]

On 10.10.10 15:55:49, Alexander Dymo wrote:
> Hey,
> I'm about to merge some stuff back to kdevelop repository and I'd
> like to clarify our preferred policy wrt merges.
> 
> ==
> Note: pls read this email with fixed-width font. If you can't, same
> properly formatted text is on:
> http://www.kdevelop.org/mediawiki/index.php/User:Adymo
> ==
> 
> Question is do I need to rebase my changes on top of kdevelop/master
> and then push to avoid merge commits
> or it's ok to merge kdevelop/master into my branches (creating merge
> commits) and then push that.

You mean merge your branches into kdevelop/master and then push that,
right? So far thats what we've done, i.e. no need to specifically rebase
a branch against 'current' master to get a linear history. Wether or not
you first merge kdevelop/master into mybranch to test against 'most
recent master' is your decision.

While many changes are still done in master directly, especially
contributor-changes are already being merged without rebase'ing and
create merge commits. And larger changes have also been done in a branch
that was then merged into master when it was ready (and master merged
into that branch every once in a while to keep it up-to-date).

Andreas

-- 
Save energy: be apathetic.