World: r3wp

Another option for explorer integration would be Git Extensions:
http://code.google.com/p/gitextensions/

(And yes, even plain msysgit comes with minimal, optional explorer 
integration in the form of "launch a git shell here" and "launch 
git gui here", if I remember correctly.)

The installer from my link above adds the explorer extension as well.

Oldes, thanks for the link to the latest version. This seems to be 
better..'only' 180MB :-)

Quick notes:


I downloaded via the Git link that Oldes posted above. It's ~12MB 
(reasonable.)


Installed fine on XP.  Yes, this is a shell version, which is fine 
with me since I like to use scripts anyway for merges, builds, and 
releases.


I have yet to try git with github. It would be great if someone could 
post the magic command line to checkout  the existing repository 
(anonymous currently),


Regarding GUI version: it would not be difficult for someone to wrap 
a few REBOL calls it to give you a bit more GUI feel. Not perfect 
of course, but something clickable.

So, next steps for A110 in git are:


1. Obtain a user account on github. (with the permissions I need 
from Andreas.)


2. Commit new A110 sources to github. (probably an overwrite, not 
a merge)


3. Commit A110 libs to github. Binary, compressed, and version/platform-dependent.

4. Tag it all as A110 (however that's done in git).


Does this sound about right with you git gurus?  Let me know of any 
special steps, proceedures, so this can happen today.

I'm using Git second day, so I'm far to be called git guru, but I 
think that you could just obtain account without Andreas' permissions 
and commit the sources under your name.

Checklist created: Git Move -- steps for A110 git-based release

Andreas, feel free to update checklist with any additional things 
that you want to add.

Oldes, mostly. There was something he mentioned to me earlier.

To clone the current repository:
$ git clone git://github.com/rebolsource/r3-hostkit.git

Ok, so that's like a checkout?

http://eagain.net/articles/git-for-computer-scientists/

Yes, that's somewhat like a checkout.

Worked. Got it. Nice.

git move checklist updated

The general model is that if you plan on making changes to the codebase, 
you usually would "fork" (lowercase) the project on the GitHub site. 
 It is not typical for people to give write access to others on their 
repository.  So that URL ( git://github.com/rebolsource/r3-hostkit.git 
) is read-only.

Carl was referring to something else, I reserved the "rebol" username 
yesterday.

Carl, to "overwrite" your local stuff with the new sources, just 
remove everything but the .git/ directory.

Then copy over your changed sources and do a "git add -u .".

A "git diff --cache" will then show you the changes compared to the 
last commit.

Use "git commit" to commit those changes.

When there are various tracks of development on forked repositories 
at GitHub, you can see the state of their convergence (or divergence) 
with the network graph visualizer: http://github.com/blog/39-say-hello-to-the-network-graph-visualizer

Gotta run now, will be back in 30 minutes.

But you do not get that if you just clone someone else's repository 
in a read-only fashion... i.e. with the clone command " git clone 
git://github.com/rebolsource/r3-hostkit.git ".  It's easy enough 
to fix later, but you can do it up front by starting with a fork 
if you know you are planning on making changes and sending them back 
to the project.

A nice feature worth noting is that GitHub automatically makes .ZIP/.tar 
for you (note the downloads button).  Available at links like http://github.com/rebolsource/r3-hostkit/zipball/master

Gabriele, it is obvious that both Git and Hg have their strengths 
and weaknesses related to each other, and the question is whether 
the tool plays to the strengths you need. One of Git's strengths 
is popularity, which has had a side effect of prompting the third-party 
development of addon tools that in many cases make up for its (not 
insignificant) weaknesses. I was not dissing Git when I said that 
its advantages was popularity - that is a considerable strength, 
not to be ignored. Things become popular for occasionally on-topic 
reasons, and it has real benefits no matter what the reason. Fortunately 
we have a good tool (REBOL) that we can use to work around Git's 
weaknesses.

A word of advice: On Windows, you might not want to use the Tortoise 
extensions. Tortoise* slows down Explorer's file and directory access 
even when you don't have any repositories or relevant file hierarchies. 
If you do a lot of file management you might want to stick to the 
CLI tools.

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.