X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=simple; d=mail.ud03.udmedia.de; h=
	message-id:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=beta; bh=YFt6Z8tfjAzu4FRCBdvTgl4eE
	plFKOkj0wHi7ZFC6To=; b=ZwaKkX7syWMN5vJxDMD8bivb5KMx4BgUIL4c3btYJ
	zlj4252ep3xogMuUWxum5TgIO4nZQb8xzRR2e9POpbO/DAT4jGbCWs8tNf2ZfXLP
	iwPAphKnng1jQcO6YLacjMcUltP7t6zL16jMf3nYgGLP7SscJXIIPArOqA0+JLVL
	Qo=
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)
X-Enigmail-Version:	1.4.6
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/

- Raw text -