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=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=7aOYkucq6X19QS9JrMlQ3HCKksAOTyPduzO6kAyxjUQ=;
	b=YzAyUND1n/CuTu6nef81dUhdEGlLGzsWJG3NZ/BiA2q4rp/nFElXPnZUdx7sZ466Lq
	jjqFemHZNibwcZu+E3jKDyBF5RsadYWYEKBOkKVx8NzTa6E0DSJ84g/qao3P5ZQZbHiA
	0OV/aUujUoamLVioZrO+uNV13lR9x9dUS/KOy9JDQnI84WQsIEwxU9fN9BN5UFBLkOOu
	Vqnzj6FqgNPaD+VC2MUurSOiLvfPbyx56+lvIaZIOB9fEEXdFUVODrW/ll79np8wVkoD
	Eockj4vx1MjXJ0Mxzyp95HX8DE0j5Z9goRYnsqVH3YYeRYO8qSpq++PeyOsAz6CifNpx
	k8sw==
MIME-Version:	1.0
In-Reply-To:	<CAC4O8c9JM0PsC66_tGAYOGAZx1vUR2ZwJr2dZCKihqt_JdfBWQ@mail.gmail.com>
References:	<CANqhZFxYH+Y5U1ai7ey-s+4nz6eYDM2vx3aMDb7WuigNXmi4AQ AT mail DOT gmail DOT com>
	<1511E63C-F435-44B1-9734-C7AF7AF49A92 AT sbcglobal DOT net>
	<20121030132922 DOT GY32696 AT fi DOT muni DOT cz>
	<201210312340 DOT q9VNe3VW012697 AT envy DOT delorie DOT com>
	<CAC4O8c-xvCH8j2h3K3+ymO0Zgbru_JqDavqojY81iT_C=-zPrw AT mail DOT gmail DOT com>
	<CAGde_xOu96b1jxN1n2km3_OAkX9umshs9FQF+Gdjgsbw_Mt4qQ AT mail DOT gmail DOT com>
	<CAC4O8c8BiPJSJyvTDs337ix2e==+bLwzz3TgqD8rV+B4TPkSxw AT mail DOT gmail DOT com>
	<k76358$9fs$1 AT ger DOT gmane DOT org>
	<CAC4O8c9JM0PsC66_tGAYOGAZx1vUR2ZwJr2dZCKihqt_JdfBWQ AT mail DOT gmail DOT com>
Date:	Sun, 4 Nov 2012 20:58:55 +0100
Message-ID:	<CAGde_xOMuuN_Gz9hdw1OJtvVDWTZGER5CoCnMpONkvi9cCHqTQ@mail.gmail.com>
Subject:	Re: [geda-user] The state of gEDA/gaf (Was gEDA/PCBs diversity, Was:
	Pin hole size)
From:	Svenn Are Bjerkem <svenn DOT bjerkem AT googlemail DOT com>
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 4 November 2012 19:18, Britton Kerin <britton DOT kerin AT gmail DOT com> wrote:
> and it should all stay)?

I don't think it needs to stay forever.
Right now, though, I think it is wise to give precise local information about
1. Cloning the local repository
2. Making a feature branch
3. Provide the feature branch as a patch. (presumably after testing it
doesn't break anything)

A git-savvy user will be able to get the source and do all this, and
more, if he only knows the location of the central repository. A git
newbe (even if he has been programming for ages) may need a bit more
assistance. The switch from svn and cvs to git is not just a walk in
the park even if svn and cvs are well known. And the upstream
developers would likely want to have patches that are easy to audit
and merge. git is so powerful that even the simplest things to do get
swamped with special cases. geda:scm shouldn't need to teach how to
use git, but a new gEDA developer should be able to do the above steps
without the need to consult another page.

Ideally, the part about adding remote git repositories should not be
necessary. Unfortunately, gEDA has forks and clones "in the wild", and
trying to pull important changes done in these repositories back into
master is something which was addressed on this list. Some forks
should maybe be let alone, because they have diverged too much, while
others should be watched closely. It looks as if most of the GitHub
clones are relatively well merged with their ancestor. Doing a remote
fetch into my local git.geda-project.org clone provides a huge, but
viewable, history in gitk. It is not illegal for a maintainer to pull
in things he sees fit the project. When gEDA devs get the hang of
providing git patches that are easy to merge, that kind of info can go
away. Linux kernel maintainers do not need to pull 'secret' stuff,
they are flooded. A different way of working.

git-flow is a concept put on top of git to make git more streamlined.
I have been using git for my own stuff at work and really struggle now
that I am supposed to pull in new people into my way of thinking. I
recently learned about the existence of git-flow, and by just looking
at those history diagrams, I understood how they used git in a much
better way than I ever would have come up with myself.
http://nvie.com/posts/a-successful-git-branching-model. I am not
saying that this is a good model for gEDA, but I guess every team, and
single user, using git sooner or later will struggle with all those
branches that are so extremely cheap to make, but can be a PITA to
merge into the correct master/development/release branch.

I had to learn to walk again after git hit me.

-- 
Svenn

- Raw text -