Cloning GitHub Access

Here is another very basic guide into GitHub usage.

After you have used GitHub for a while, you will have a desire to spread that usage over all your machines.

You would like to clone from GitHub from your notebook, from your machine at work…

To get this, you have two options:

Create an SSH key on each of those machines, and add then to your GitHub account.

Or you can replicate your single current SSH key on all of those machines.

To achieve that, all you need to do (In Windows), is to copy these files / folder from your original GitHub access machine home path to the others.

C:\Documents and Settings\Ricardo>
C:.
│   sshkey.txt.pub
│   sshkey.txt
│
└───.ssh
    id_rsa
    id_rsa.pub
    known_hosts

That is it.

I would like to ask you all from Linux and OS/X, to comment here how to do the same on these environments.

github primer: the real one

All the articles I have read about getting started on github are not so “primer”.

Take for instance, my favorite article on getting started with github:

Getting Started with Git and GitHub on Windows.

It does a great job, until the “Set up your GitHub account” picture.

After that it turns specific, and supposes the readers will fork his project…

Others, starts the action by cloning an empty repository, which makes no sense.

This primer, is supposed to be your very first incursion into github, so, I will not give you the entire alphabet, just the “A” letter.

I’m supposing you have already installed your git client and done with your github account, now what?



Everything is empty on my github account. What can I do next?

First you need to create a new Repository:

You just need to fill out this form:


With at least the Project name which will become the Repository name.

Or (that was my case), just rename an unused one with the desired name:


This will let you with something like this:


With your own “Clone URL”, that will be used on the next steps.

Now let’s go and create some content and push it into this new Repository:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

E:\GitHub>md mynewgithub

E:\GitHub>cd mynewgithub

E:\GitHub\mynewgithub>git status
fatal: Not a git repository

E:\GitHub\mynewgithub>git init
Initialized empty Git repository in E:/DreamHost/GitHub/mynewgithub/.git/

E:\GitHub\mynewgithub>git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)

E:\GitHub\mynewgithub>notepad readme.textile

E:\GitHub\mynewgithub>dir
Volume in drive E is Dados
Volume Serial Number is 5C89-E09F

Directory of E:\GitHub\mynewgithub

01/01/2009  04:38 PM    <DIR>          .
01/01/2009  04:38 PM    <DIR>          ..
01/01/2009  04:37 PM    <DIR>          .git
01/01/2009  04:39 PM                77 readme.textile
             1 File(s)             77 bytes
             3 Dir(s)   5,366,173,696 bytes free

E:\GitHub\mynewgithub>git add .

E:\GitHub\mynewgithub>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file: readme.textile
#

E:\GitHub\mynewgithub>git commit -a -m "My first commit on github ever"
Created initial commit f213d62: My first commit on github ever
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 readme.textile

E:\GitHub\mynewgithub>git branch
* master

E:\GitHub\mynewgithub>git status
# On branch master
nothing to commit (working directory clean)

E:\GitHub\mynewgithub>git push -f git@github.com:marcric/mynewgithub.git master
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 291 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:marcric/mynewgithub.git
+ 2fdc3ed...f213d62 master -> master (forced update)

E:\GitHub\mynewgithub>

And then, supposing this is the “readme.textile” file content:

h1. That is my first github project

h2. And this is my first README file

You will have something like this:


Now it is OK to start forking, cloning, merging and what ever you want to do with git on github.

Rails 3.0 – LIVE, released!

Or: How to NOT kill a brand.

WTF: a Play Station 3! What is this article about? Something I hope will NOT see in the near future.

Sometimes it is difficult a great brand to stay on top. And if that brand is an Open Source one…

Open Source philosophy is sometimes dangerous. Some people out there believe Open Source means “truly software democracy at work”, if you don’t like it, choose another one, or do it for yourself. Well; it is OK thinking that way if you have no serious business attached to an Open Source technology. Did someone asked how many production projects are running Rails 2.2.2? Or even Rails 2.0? Or Merb 1.0.5? Or even Merb 1.0? Why so many releases? Why so close?

Look at this Merb – Rails, so called “merge”. In between the lines we can Read: Rails “eats” Merb. But that is not necessary a bad thing. I think we are just on a high level of WTFs per hour on this subject. BTW, the best “merge” definition I have got is: “To blend gradually into something else”.

I’m a newbie here, I’m focusing on Rails, just because a newbie need to focus on something, but I have made a fast incursion on Merb at RubyLearning (beta course), and I need to say: I like what I have seen there. The only drawback was it wasn’t working fine on Windows, but I think they have fixed this on a later version, so…

Now back to the point: I don’t care if they call it Merb or Rails, but it is fair to keep the bigger market share brand, so, we can say the brand Rails “eats” the brand “Merb”. May be it is time to find a new real OPEN SOURCE logo (that is for DHH) and improve the brand into something like “Rails 3.0 – LIVE”, to celebrate that.

But the same COULD NOT be applied to the teams, they MUST be merged. That is what I really care about.

The way they will move from now on, will make history (or not). They have established the brand: “Rails 3.0” it is, but which is the strategy?

I think they must have a common focusing point on Rails 3.0, two in fact:

• Convince Merb users that they can upgrade to Rails 3.0 and their project will remain almost the same, and they will not need to “rely on Mack, Waves, Sinatra and others to fill in the gap”.

• Convince Rails users that the new options and technologies available will not necessary change their projects a bit, will not introduce new bugs and if they want Rails will remain as opinionated as it is now.

There must be a mission: “No pain, plenty of gain” for both current brands users.

I have read that “Merb will keep on living and be supported for a very long time. (we will keep on fixing major bugs even after rails 3.0/merb 2.0)”.

To be honest, I think it is a bad idea. It means the newcomers on the Rails core are still attached with their old brand, and if that is the point, they will be a team inside a team, not a merged team with a common objective.

So people from the Rails core: the older ones and the newcomers, PLEASE, THIMK.

The users, THE CUSTOMERS, don’t need two brands for so long IF the remaining one gives the options they need, so, keep in mind the two focusing point mentioned above and MOVE ON.

A real and complete team merge MUST be done when Rails 3.0 get released.

And Merb support MUST be ended with Rails 3.1 or Rails 3.2 at least.

Or, you can remember the classic: “How to kill your brand”. Coincidentally or not, they were talking about version 3 at that time too.

I hope there will be a time in the future we can say: we believe they two become one.

Merb is DEAD

Well, I don’t think so, in fact I think Merb is now immortalized, just because it twist a fundamental concept on Rails World, which is: “Rails is an opinionated Framework”.

You can see all sort of reasons, why people adopt Merb or Ramaze instead of Rails and use other alternatives on the full stack like Rack and Thin, all over the place.

Since Rails could now dress all Merb good features, reasons to start developing a “new” framework against Rails, will start to diminish from now on.

Here are the basics on Rails 3.0 prototype on the table:

"Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty (“rails myapp --core” and “rails myapp --flat”)."

"Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over."

"Rails will always have a default answer to every question within the stack. But you will have the option of your choice on: TESTING, ORM, TEMPLATING, AJAX. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives."

"Too many plugins break when Rails is updated. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades."

"The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 (May 4 to 7) in Las Vegas."

On the other hand, there are some side effects over the earlier adopters of Merb: speeches, keynotes, courses and books and even applications, are now on the spot. What to do?

Rails’ official blog announcement.
Rails’ official site announcement.
Yehuda’s blog announcement.
Ezra’s blog announcement.
Matt Aimonetti's blog announcement.
Carl Lerche’s blog announcement.
Lori Holden's reply.
EngineYard’s blog announcement.

Well, that is it.

Marry Christmas!