Message-ID: <52224709.9030800@jump-ing.de>
Date: Sat, 31 Aug 2013 21:42:01 +0200
From: Markus Hitter <mah AT jump-ing DOT de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: [geda-user] Workflow in pcbs' central Git repository (was: merging vs. rebasing)
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com


To clear up this conversation a bit, let's have a look what another
popular project, Wine, does
(http://wiki.winehq.org/GitWine#head-dae615e1441dcf16515ca6a96ef19a69fa208061):

> Git allows you to merge branches together; this is not done in the 
> WineHQ repository, so it is easier to just rebase/cherry-pick 
> instead.

Also it turns out Peter Brett actually uses a lot of rebasing for
himselfs, too, and even recommends to use "stgit", a tool easing
such a workflow. Cite from the geda-developers list, talking to me:

> Am 30.08.2013 20:03, schrieb Peter TB Brett:
>> Both pcjc2 and I use stgit for our personal work.  I recommend it 
>> to you, because it sounds like you might find it suits you (...).

Accordingly, the only topic remaining is, wether this workflow
can/should be moved into the central repository. For better
collaboration, more developer convenience and most importantly, more
public visibility of the projects' work.

Here's a proposal for a simple set of rules which builds upon pcbs'
workflow (rebasing happens for years already!) of the last 3 years and
should make everybody happy:

1. Don't change the history of master, a release branch or anything tagged.

2. In all other branches, do what you think is right. Local branches as
well as ones in the central repo.

3. If you didn't create the branch yourself, create your own or talk to
the person (bug discussion page!) who did.

4. Feel free to add as many branches as you need, ideally one per
development target (e.g. fixing a bug).

5. Pushing local branches to the central repository, even if they're
work in progress, is welcome. This way others can see what you do and
double-work can be avoided.

6. If you think you're done, rebase the branch onto master and ask for
testers.

7. If testing was successful (currently this means: nobody complained
for a while), rebase onto master again and cherry-pick all the commits
over to master _or_ merge the branch into master (same result for
different tastes).

8. You can do 6. and 7. partially, i.e. pick only unambiguous commits
over to master, then iterate.

9. Delete the branch if the branchs' target is reached and there's
nothing left to keep.


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/