Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
To: internals@lists.php.net
References: <slrnjl54vo.mfm.dsp@experimentalworks.net>
	<CAKOpQSzFq9ZeJRk43Wj2enF2f0g6gdRxT0d25h=KTsH0V4w9xg@mail.gmail.com>
	<87zkbwby4d.fsf@gmail.com>
	<CAKOpQSxuXfK4OGab29tKQEKq3_v-_DC-+3xC2rwOr7vF4LRAhQ@mail.gmail.com>
	<4F536486.6050801@lsces.co.uk> <87aa3wqv6u.fsf@gmail.com>
	<4F539B2B.9050308@lsces.co.uk>
Date: Thu, 15 Mar 2012 23:36:34 -0400
In-Reply-To: <4F539B2B.9050308@lsces.co.uk> (Lester Caine's message of "Sun,
	04 Mar 2012 16:41:15 +0000")
Message-ID: <87ehstcj3x.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PHP-DEV] Git Migration: Status Update
From: jeremiah.dodds@gmail.com (Jeremiah)

Lester Caine <lester@lsces.co.uk> writes:

> jeremiah.dodds@gmail.com wrote:
>> I hope that clarifies things a bit. It definitely doesn't make grokking
>> things a whole lot easier, and it is certainly *possible*  to follow a
>> very svnish workflow using git (and may sometimes make sense to,
>> although I am struggling to thing of such a time).
>
> I've been using Hg myself for the 'DVCS' style of working. This allows me to
> publish my own ports of things which others can follow, but from which I can
> push things back to the original project as required. I'm still not convinced
> that the 'production' branches such as PHP5.3 can be run without some element of
> management, although of cause a release will still be packaged as a tarball set
> and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10
> ... as I require it direct from the repo but some of the projects I am working
> with have now lost the 'master' codebase simply because groups of developers are
> now doing their own thing. The overall flexibility of DVCS still needs a mindset
> of maintaining a code base that follows the master route plan? Which may well be
> a more 'svnish' way of working when testing and committing production ready
> code?

I use Hg at work, and while it's a pretty fine DVCS, it's more in line
with SVN's mindset than git's in parts. Namely, Hg focuses, afaict, on
making it easy to move the commit history forward in time by abstracting
over the manipulation of the DAG. Git focuses on manipulation of the
DAG -- the line between locally-visible and remotely-visible stuff is
more blurry in Hg than in git, and it feels like you're using the tool
in unintended ways when you clarify that line in ways Hg doesn't
expect. That's not necessarily a bad thing or whatnot, just a thing.

> The question I think that needs to be asked is 'should experimental development
> branches exist in the master code base?' all very easy to do with DVCS, but is
> it practical.
> Does it not make sense to clone the experimental work from another
> source, and keep the main codebase tidy with just proven pushes that follow the
> production path. There is nothing actually stopping someone producing their own
> private branch and sharing that while it is being developed, just pushing the
> results back to the relevant master branch when development work has been
> completed?

If the experimental branches are long(er)-lived and worked on or of
interest to people who'd be checking out master, sure. There's
definitely a balancing act -- you don't want 500 experimental branches
laying around yer main repo, but that probably won't happen, in no small
part because when you merge the experimental branch in to a master
release you can just delete it. The commits won't be lost, but it won't
be showing up in `git branch -ar` or whatnot -- the branch is just a
pointer to a node in the DAG to git.

There isn't the concept of "permanent always-stick-around-branch" like
in Hg, unless you decide to make it so. 

For a good example of "hey keep these relevant branches around on
master", take a look at https://github.com/symfony/symfony . There's a
few branches sitting around on their main repo at any point in time --
the master, development branch, maybe some other feature,
whatever. Like you mention, people interested in a particular niche of
the framework are pulling from branches on each others git repositories,
and there are a ridiculous amount of branches in the ecosystem, see
https://github.com/symfony/symfony/network .

For a bad example, look at the git mirrors of emacs (at least the last
time I looked at them). Yeah, there's reasons for it there, but the
point is that having too many of them produces noise. Which is true.

I don't think there are any hard and fast rules here, but at least git
makes it easy to change things up if they lean too far in either
direction.