[phobos] std.process on github

[Russel Winder]

On Mon, 2011-01-24 at 06:05 -0800, Jonathan M Davis wrote:
[ . . . ]

> Well, it's going to be a bit of a learning curve for most of us I think. I've 
> used git a fair bit, but only on my person stuff. I've never collaborated with it 
> (aside from using git-svn to communicate with an svn repository), and I've never 
> used github. But from the comments thus far, I get the impression that most 
> people around here don't even have that much experience with it. So, we've all 
> got a bit of learning to do. It should be a big improvement though, once we've 
> got the kinks sorted out.

With the Gant and GPars projects, we found life became so much easier
using Git than Subversion, even though people had to learn not only a
new command set but a whole new way of thinking about version control.
If using Eclipse or IntelliJ IDEA then the Git plugins are very good.  I
don't know about Code::Blocks.

As long as people just say to themselves "we have made the change, don't
look back" you'll find everything shakes out quickly and things become
better.

A few thoughts stemming from our experiences -- I don't think any are
contentious but . . . :

Use remote tracking branches -- they are Git's greatest contribution to
DVCS.

Remember your repository is your fork of the project, you do not have a
checkout of trunk.

If your repository seems to get incomprehensibly broken, don't try and
fix it, get a new clone of the central master repository.

Don't rely on GitHub, use GitHub as needed.  Personally I just use
GitHub as a place to put a mirror of my repository for a project.

Only commit to the central master repository finished changesets that
everyone agrees on, never put feature branch stuff into the central
master.  The central master should at all times be a pristine repository
that by definition is the agreed state of the project.

Some of the commands of Git are highly complex, always remember they are
and don't try and treat them as simple.  Some of the parameter syntax
can get very perlesque.

Git's "index" is weird compared to other DVCS.

Use gitg, gitk, gitgui, git-cola, qgit.  Personally I am a bit of a gitg
addict.  The point is that you have a whole repository with an
increasing number of branches and you need to visualize them.

Get into the habit of using feature branches.   Create a branch for
every new bit of work.  When the work is ready, merge into your
publishing branch and announce a pull request.  Other people can then
pick up your change and integrate it into their repository as they see
fit.  Working with feature branches allows people to experiment
collaboratively because everyone can work on the same changesets.

Keep your named branches that are tracking branches of the central
repository pristine so that you have a local mirror of the current
agreed state of the project.


I could go on, but it will probably get boring.


-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110124/def536d4/attachment.pgp>