World: r3wp

Encouraging!

What would be nice is to boil that tutorial down to just the 1, 2, 
3 steps that most R3 developers would need to know.

Agreed.

Be sure to include the right settings to choose for the Windows installer.

So, for github, would each developer have their own repository on 
that site?

Would be a possibility, yes.

Attaching patches to curecode issues is another.

Brian, any other setting besides the CRLF that you remember?

Also, how is that set on Linux? Not sure.

Linux does the sane thing per default :)

So... what's the general flow. For example:

1. developer clones host-kit repo
2. makes changes as needed
3. commits to local repo


Then, developer must somehow put them somewhere that we can pull 
from, correct?

Yes.

So, there's no "push" is there?

4a1. developer exports commits as patches
4a2. developer attaches the patches to a curecode issue

Do the CRLF-local, LF-repo on Windows; LF local and repo on Linux. 
Then line endings will be normalized. Only applies to text files 
of course.

4b1. developer forks the r3-hostkit repo on github to his github 
user account
4b1. developer pushes his changes to his github fork

4b3. developer notifies upstream via r3 chat, altme, curecode, or 
even github pull requests.

So, there's a git patch command to emit patch file?

Or does user do that manually?

git diff emits patches

git format-patch emits patches that are ready to be emailed

is the "fork" you mention for 4b1 the same as a clone?

The specific "forking" I was referring to is a Github feature.

ok

We can quickly try it out, it is really simple.

But if you have a look at
http://github.com/earl/r3-hostkit

You will see that at the top there is a link "forked from rebolsource/r3-hostkit".

When you look at
http://github.com/rebolsource/r3-hostkit/network/members

Whoops, I'm being called to dinner. Will be back in a while, and 
will check that out.

You'll see that Github lists all "forks" there.

Enjoy!

bye for now

Brian, the only trouble with letting git do the line ending normalisation 
is that it is a bit troublesome. It's generally easier to just have 
git not touch the line endings at all and use a properly set-up editor 
instead.

Oh, I was used to Hg just doing that without the problems. Can we 
reject submissions that don't have the right line endings?

Yes.

And I assume every major C/C++ compiler on Windows can handle LF-endings 
with no complaint.

We only have to support one that does.

Is there a pending proposal to fix git's line ending munging so it 
works properly, like Hg's?

(-> "Source control")

Useful git guide: www.sourcemage.org/Git_Guide

Shows examples of many commands. In FAQ format.

A few examples there are a bit out of date, though.

For example, git-update-index is no longer needed to resolve merge 
conflics. You'd use git-add instead.

And in the "advanced usage" examples, a few commands have been simplified.

A question: for new releases, should I push to my carls repo, the 
rebol sandbox, or r3-hostkit ?

Asked another way: how does r3-hostkit get updated?

Do we always pull into it?

I would push into rebol/r3-hostkit for now.

(Which does not yet exist.)

The rebol/sandbox is just if you want to play around a bit with Github.

We'll probably just delete that afterwards.