AltME groups: search

Also, would be good to recommend a Git client for people to start 
with.

Git's primary UI is a CLI.

For SVN write access you'll need to create an account on Github, 
though. For Git write access, I can just add SSH keys which are allowed 
to write to a particular repos.

When installing git from distro packages, just make sure you get 
a Git newer than 1.6.0.

A "concise summary" may be a bit problematic, as distributed version 
control really is a bit of a paradigm shift compared to CVS or SVN.

http://gitref.org/has what many consider a very good tutorial. Concise 
it is not.

Github is a good site, but there are a few issues, such as how they 
do not acknowledge the .r extension as Rebol.  I've gotten them to 
do .r2 .r3 and .rebol however.

I would like to see a similar site for Mercurial - it likely has 
advantages over Git, particularly on Windows.

There is a bug in the syntax highlighter GitHub is using (pygments) 
which causes infinite loops if you write comment [ ( ) ] .  Annoying 
but probably easy to fix if someone wanted to.

I am always running out of disk space, no matter how large a disk 
I get. But I was more disaproving of the vast number of dependencies.

but msysGit seems to manage all of that into a single download and 
install, so it seems to not be such an issue.  (not like MinGW which 
requires to use its rather obscure and poorly documented package 
downloader)

If you decide to go with Git because it is popular, cool, no problem. 
I haven't yet seen a good argument that Git is better (than Hg, at 
least), but popularity has its own advantages.

Github is a popularity argument. And a good demonstration of the 
advantages of popularity.

One of the things I like about Git, and am quite proud of, is the 
data structures are simple and you can reimplement it if you wish. 
It's a well-defined data model. There are Git-related projects like 
GUI tools, for example, with the Eclipse IDE.

   http://www.computerworld.com/s/article/print/9126619/Q_A_Linux_founder_Linus_Torvalds_talks_about_open_source_identity

I've said before that a concrete and vetted reimplementation of an 
unnecessarily complicated (but popular) tool in Rebol to show how 
teeny it could get would spark great interest.

But doing one in REBOL is likely a good idea.

It may still have a future for the next Altme

Git is not particularly difficult in and of itself, but the model 
people typically use in GitHub adds a little layer of complexity 
to it with "pull requests" and things... the good news is that with 
a little patience and asking the large community for help you can 
get things going.

Quite a few people here know it ... so don't worry

There's a wide variety of models you can use.  If you really want 
to, you can authorize people other than yourself with write access 
to your repository and it then works a little more like traditional 
centralized source control.

btw - can Tortoise SVN be used as a GIT client, or is that something 
different? I like how I upgraded RebGUI - what was the system RebGUI 
used based upon?

... but you would not have to constantly announce it - it could save 
you a bit of work, no?

Pekr, that's simply a snapshot, which takes a minute to do, thanks 
to our build system.

its easier to do a grid of different setups. not just a linear sequence 
of versions.

I haven't yet seen a good argument that Git is better (than Hg, at 
least)

 - Brian... so... people who have used both for years can be just 
 ignored I guess.


Just read how they work, if it's not obvious why GIT is better, then 
I don't know what to say.

I mean... didn't I use an OS that fit on a 512kb rom just 10 years 
ago... seems like a lifetime ago.

The idea of GIT might be good, but where do we end up, if we suddenly 
rely on 3-5 different systems that require a 10GB installation of 
all sorts of unmanagable components?

once we have ssh on r3 (in whatever form) I think we should be able 
to build the entire git toolset with REBOL at a fraction of msys 
stuff.  I already did a complete source control system (though with 
a completely different model) called distro-bot and its hardly 1GB!

rebol in and of itself already does most of the low-level OS stuff... 
just two days ago... I used R2 as a delete function in order to polish 
a windows GCC script.  this strikes me as a similar situation where 
rebol could be used to probably replace a sizeable portion of the 
msys stuff... though it might not be as fast and optimised... that 
I do concede.

Yes, msysgit is just a CLI

tortoisegit just adds a kind of explore integration that many are 
already familiar with.

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

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.

Ok, so that's like a checkout?

Yes, that's somewhat like a checkout.

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.

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.

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

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

But one step at a time :)

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 :)

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.

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

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.

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.

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.

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

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.

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

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.

Had the chance to read Git for Computer Scientists.

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

Strolling down a dangerous road...

First, let me see if I can grab a working AltME for this linux box... 
so I don't need to keep looking back at a different screen ;)

Sure a lot easier installing AltME on Linux than most other apps. 
:)

No, just a humble scrappy coder.

I can write a small REBOL script to sync the source over to the other 
build systems... which will probably never have the ability to run 
git.

If you're using a HP/UX from, say, 1990, you'll probably be out of 
luck, though.

Not a good strategy on some forward-lookin platforms, though.

Let me see if I can find a curl-config that runs... then I can try 
the build again.

You'll probably need to adapt your apt source, since breezy has been 
archived for a while.

compile goes a long way... blows out at http fetch.

The system itself is simple. Comes with a load of features, though.

So, that clone gave me a full local repository, right? So, I can 
mess around with it... to get to know it?

git gives me a warning that templates are not found in my git-core 
dir

Would be a possibility, yes.

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

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

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

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

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

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

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.

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

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

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 ?

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

Of course you can also create a repo under your carls user for playing 
around.

Is there a command for renaming files?

If I remove a file from my repo, then I push . does it remove it 
from the target repo?

If you remove with git-rm, then create a commit with git-commit, 
then git-push: yes.

If you remove with something else, you'll still need to create a 
commit for that remove.

That's just a convetion I use to refer to commands.

Well, I must say... I am impressed so far. There are a lot of "nice 
touches"

I think many people have gone to use SVN and will resist a bit using 
something new.