Aside from the fact that I've never used or understood git, anything is probably better than using subversion 1.4 which has zero merging support :)

I just created a github account, and the username is ..... schveiguy (I know, very surprising).  Please add me as a contributor to phobos and druntime.

Man I hate it when web sites require you to use certain characters in passwords...

-Steve



----- Original Message -----
> From:Lars Tandle Kyllingstad <lars at kyllingen.net>
> To:Phobos mailing list <phobos at puremagic.com>
> Cc:
> Sent:Monday, January 24, 2011 6:03 AM
> Subject:[phobos] std.process on github
> 
> This message is mainly for Steve, but I thought I'd send it to everyone because it demonstrates how much more convenient it is to collaborate using Git.
> 
> The new std.process has lain dormant for a while, waiting for some DMD bugs to be fixed.  This has finally happened, and we can pick up where we left off.
> 
> So I forked the Phobos repo,
> 
>         https://github.com/kyllingstad/phobos
> 
> added a new branch, corresponding to a local branch on my computer,
> 
>         https://github.com/kyllingstad/phobos/tree/new-std-process
> 
> and finally I operated the changes locally and pushed to the Phobos fork:
> 
> 
> https://github.com/kyllingstad/phobos/commit/347ce117eb1e0bff94c4387a0f1599a31ef8374d
> 
> While I could have done all of the above before, what makes this so awesome is that I can now keep the development branch up-to-date with the main Phobos repository at all times.  (I tried the same with the devel/new-std-process branch in the old repo, and SVN borked the whole thing on the first merge.)
> 
> 
> Steve, it should be all ready for you to pull my changes and add the Windows stuff at your convenience. :)
> 
> Note that I dropped the UnbufferedFile stuff and reverted to using File everywhere.  This is because a) Andrei has said he intends to add buffering control to File, and b) we may want to integrate pipes with the upcoming std.stream.  Is it OK with you if we go with File for the time being?
> 
> 
> -Lars
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Monday 24 January 2011 05:50:32 Steve Schveighoffer wrote:
> Aside from the fact that I've never used or understood git, anything is probably better than using subversion 1.4 which has zero merging support :)

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.

> I just created a github account, and the username is ..... schveiguy (I know, very surprising).  Please add me as a contributor to phobos and druntime.
> 
> Man I hate it when web sites require you to use certain characters in passwords...

What's worse is when they insist that your proposed password has words in it or consecutive this or that when it doesn't, and so they refuse your password (though fortunately, most sites aren't anywhere near that picky). I had to change my password on a site like that about a month ago, and I think that it took me about half-an-hour before I gave up and just created totally random gobblegook for a password and relied on my computer to remember it for me, because I sure wasn't going to remember it.

Generally, the two things that I find most annoying are when they _don't_ allow certain special characters (too often they're special characters that nearly all of my passwords have) or when they require a _maximum_ password length. Virtually all of my passwords are long, so coming up with decent short ones can be hard.

- Jonathan M Davis

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>

Le 2011-01-24 ? 12:26, Russel Winder a ?crit :

> 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.

And the great thing about it is that you don't need commit access to the central repo to maintain a topic branch.

For instance, here's my fork of the dmd repository which has two topic branches I just rebased on the new official git repo (const-object-ref & d-objc). Now, merging them with the official dmd repo is just one "pull" away for Walter. :-)
<https://github.com/michelf/dmd/>

Also mirrored here:
<http://git.michelf.com/dmd-objc/>

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

On 01/24/2011 09:26 AM, Russel Winder wrote:
> If your repository seems to get incomprehensibly broken, don't try and fix it, get a new clone of the central master repository.

Most of what you say is great advice, but I disagree on this point. Once past the novice phase, it's almost always preferable (and relatively easy) to restore sanity without starting from scratch. Furthermore, it's valuable to keep the same repository over the long term, because the reflog makes it possible to find discarded revisions from, say, last month.

Thanks,
Jason