World: r3wp

The file organization and naming is completely different in a108+ 
now too. They really are separate.

Btw, I strongly recommend doing a:
$ git config --global color.ui auto

Which will instruct git to use ANSI colors in command output to the 
terminal.

Also do not miss doing the git config to set up your email and name 
information in the commits.  Otherwise it will swipe that from your 
local machine name / localhost: http://help.github.com/git-email-settings/

GitHub hides the address and replaces it with your user name on the 
site... if you have one registered.  But anyone who clones the repository 
will have access to the address you list.

(By looking at the commit log.)

The git installer is asking what the line ending conversion policy 
should be - what should I use? Before you answer, let me point out 
that some of the new script features (notably checksum) are line 
ending sensitive. Shall we establish a rule to use Unix-style line 
endings in committed source? And then tell people that script checksums 
of uncompressed scripts will break if you convert to your local line 
endings? Note: Binary-encoded compressed scripts will also break 
if they are transmitted in text mode, but script-encoded compressed 
scripts will be fine; nonetheless, we should probably not accept 
compressed scripts of any kind in the official repos.

Carl, if you just installed without paying attention to that setting, 
you might need to change things based on the answer.

Use "commit line endings as they are", and Git does not interfere 
with line endings. This is usually easiest to handle.

OK. And then I will remember to never initially create a source file 
with CRLF.

That will be a real problem for most REBOL users though, as they 
use Windows.

That's a separate decision, then.

Yes, but on topic for managing the build process. Hence the question.

As Carl correctly said, "If C code line terminators are effecting 
your tools, I suggest you get better tools."

As long as we are using something consistently ...

Carl's call, I guess.

I would recommend using Unix line endings in the repo, whatever you 
like locally, and just not allow script checksums or compression 
in the official repo.

Agreed. Would be my choice as well.

Yup.

Want to reiterate: Bravo for taking this step, you guys.

I know it's hard to use an unfamiliar tool, and I empathize with 
BrianH's observations about how Linus's Git implementation does have 
a hefty dependency stack (if you don't use Linux where all that stuff 
is taken for granted).  If you're trying to stage a revolution in 
software methodology it might seem a bit like you're sleeping with 
the enemy...

I have a github account now: BrianHawley. Next week I will be putting 
up repos for R2/Forward and the loadable version of R3's module system.

There'll certainly be things you want changed and improved, and I 
think the best way to do that is to insinuate Rebol into the predominant 
toolchain rather than see it as its own completely parallel universe. 
 Github itself is based on Ruby on Rails, but they're using a python 
syntax colorizer.  If a tool is good, it can get slipstreamed in... 
and Rebol is so small that it could do the same, if it just mellowed 
out and became a little less prickly...

Is it possible that if we add enough REBOL scripts, GitHub associates 
.r extension to REBOL?

Rebol is not the only language where file extension issues come up, 
but they're trying to take the sort of Apple philosophy of "we'll 
figure it out" as opposed to there being a web of settings.  It's 
just not high on their priority list to "sense" whether a file is 
Rebol or not.

But long term that's what they want, to sniff and guess instead of 
offer settings.  The GitHub people are very pragmatic, and opinionated, 
and (in my experience) quick and efficient.

The new default lookup extension for IMPORT is .reb, so maybe we 
can use that, or .r2 or .r3 for version-specific code.

I saw the .reb thing.  They would probably do that.  They've already 
given Rebol .r2, .r3, and .rebol ... tekkub and I seem to have a 
little bit of a rapport now so I could probably ask him to do .reb 
too

But still, why not .rebol ?

But you have to remember that R is really established, so it will 
be hard to take .r away from them in Github.

(-> "Source Control")

They were talking about recognizing the rebol header, that's what 
they want to do, they just don't have the priority.

I imagine that if RT said "hey we'd like to be your customers and 
pay you for a closed source hosting account of capacity X" then for 
some X they'd accept adding that sensor to the system as a priority.

Without that, they tend to their paying clients priorities first, 
I think.

Good point :)

You could add it to gitorious trivially, or run your own gitorious 
installation which favors .r for Rebol, but outsourcing things like 
this seems to me like it's worth every penny... esp when it's free.

Fork, _please_ move this discussion to "Source control".

Had the chance to read Git for Computer Scientists.

Any system that has a "rebase" cannot be all bad. ;)

rebase rocks :)

Checking for git on local ubuntu.

nope. not found

up until 10.04 the package is called "git-core"

for anything before 9.04 (jaunty), the packaged git-core is rather 
old, so you're probably better off installing from source.

yes, I was concluding that same thing.

git does not make

Strolling down a dangerous road...

Why should git be dependent on curl-config ?

must be what he uses for ssh.

you'll need:
libz-dev
libcurl4-gnutls-dev
libexpat1-dev

and probably also:

asciidoc, xmlto, docbook-xsl, subversion, libsvn-perl (or libsvn-core-perl), 
unzip, tcl85., gettext, cvs, cvsps, libdb-sqlite3-perl

(those should all be valid package names for ubuntu)