World: r3wp

Is there any chance to put momentum behind a Rebol Git?  The file 
format is fixed, and documented.  Git clones have been written in 
C#, Java, maybe others I don't know about.  I have bemoaned the lack 
of apples-to-apples comparisons in software methodology... if Rebol 
wanted to prove itself, a Git clone is exactly the kind of thing 
I was thinking of.

It would get people's attention if it were microscopic and yet had 
full functionality.

As we have decided to use Git, such a thing is likely :)

If it were divided up and made  team effort, it shouldn't take too 
long.

It's an order of magnitude easier to write something that's already 
spec'd and designed where questions have been hammered out than something 
you have to design as you go.

(Please move the general source control discussions to "Source Control" 
for now, and let's keep this on topic for the R3 efforts.)

It was just a reply to Gabriele. My side of the discussion is done 
:)

Can the Mezzanine get put in on GitHub also?  Right now the only 
way I know to read the mezzanine is to source a function... and clearly 
whatever comes in the distribution has any commenting taken out...

Fork, yes I'll post the full mezz there too.

But one step at a time :)

Fork: it makes sense as well, because for instance, Brian and I go 
back and forth on revisions related to load, modules, start, etc.

Andreas, thanks for posting the above notes.

You will like the ability to have discussions attached to specific 
lines of code.  http://github.com/blog/42-commit-comments

So, to be clear, and according to the other notes posted above, when 
I make my changes, they will form a new repository??

You might consider a separate repo for the R2 mezzanines as well. 
We still have 2.7.8 to work on :)

Nope, not necessarily.

In git, every repository is self-contained.

You can move objects between repositories by "fetching" and "pushing".

B: true

You can have the R2 mezzanines be on a branch in the same repository, 
there is presumably some overlap and cases where you want to apply 
commits to both.

A: ok...  taking a break to read the git for cs you posted.  Need 
to adjust my thinking coming from the classical RVS/CVS/SVN frame 
of mind.

So you work in your local repository, create commits, and when you 
are ready you push your changes to a remote repository.

Not really, Fork. The mezzanine code has to be ported by hand, for 
various reasons. Small but significant tweaks are necessary. Different 
directories in the same repo would work though.

The respective command for that is "git push".

You can work with remote repositories either by directly referring 
to URLs, or by locally associating symbolic names with the URLs (git 
calls those local aliases "remotes").

Brian: You can have as significant differences on a branch as you 
want, and you can name the branches.  You can peruse the branch heads 
independently, like this: http://github.com/mojombo/god/branches

It's not necessary that branches ever actually be merged together.

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?