Archive for July, 2007

Serving git through SSH

Wednesday, July 25th, 2007

Hello all,

This is really simple to do once you know how git works.
If you managed to follow the previous post, the only thing you have to do is start a sshd in you server machine and add users to it.
Remember to use

git-shell

as the shell to your users ;-)

When cloning a repository, you should use:

$ git-clone git+ssh://username@/path/to/project.git/

And that's all. You can pull and push via ssh.

Simple isn't it?

VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)

The easiest way to serve a git-server (locally)

Wednesday, July 18th, 2007

Hi all,

After a while without posting I'm back and we'll see how to serve a git-server through a ssh tunnel.
This is the easiest way to serve git to other users. It'll be quite a few steps, but in the end it'll be just nice to serve git to others.

We're assuming here you have some "untracked" source code and want to serve it through git. So let's start.

First of all, let's create a user to own our sources:

# adduser devel

And now add our own user to devel group:

# adduser username devel

We now create a folder called git inside /home/devel:

$ mkdir git

Obs: we're using user devel here.

Let's say our project name is 'Project', so let's create its gittree:

$ mkdir project.git

Obs: the .git at the end of project is needed

And now we initialize a bare git tree and share it to all group users:

$ cd project.gitproject.git$ git --bare init --shared=group

Now we go back to our user and initialize a git there. We'll also configure a remote called origin which is where we'll push our sources:

$ cd /path/to/our/sources$ git-init$ git-config remote.origin.url /home/devel/git/project.git/

Ok. We now have our local gittree initialized and ready to send patches to our git server but we have no commits in our tree (remember, we're assuming you have an untracked source code tree).
We need to add the files to our local gittree and start commiting them, after that we can push those commits to our local server tree:

$ git-add .$ git-commit -s

Obs: remember to clean-up your tree before git-add'ing the files. Whithout cleaning it up, you'll probably commit some garbage like .o files, ~ files, etc.

We now have an initial commit on the project, which we're gonna push to our server tree:

$ git-push origin master

And it's all done. We can use a gittree through a local server now. Next post we'll see how to serve it through SSH. It's quite simple once you really understand locally serving gittrees.

See y'all

VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)

git-config: Configuring your repository

Tuesday, July 10th, 2007

Hello all,

We said we'd take a look at git-config before keep going. So let's go...
This post will be some kind of notes. I won't explain in a detailed way since it's not difficult. You just need to see the commands and you'll be able to understand what's happening:

This will export your name for all git repositories, don't worry when commiting again.

$ git-config --global user.name "My Name"

Same as above, but for email

$ git-config --global user.email mymail@mydomain.com

Use your smtp server when git-send-email'ing

$ git-config --global sendemail.smtpserver smtp.mydomain.com

Stripping whitespaces before commiting

$ git-config --global apply.whitespace strip

Use the .diff extension when git-format-patch'ing

$ git-config --global format.suffix .diff
VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)

Updating the Tree and Tracking Patches

Friday, July 6th, 2007

Hello again everybody,

Now we need to learn how to update our git tree (and of course, all of its branches).

issuing:

$ git-pull

In the master branch will pull and merge every single new commit locally. To update our local branches we just need to issue:

$ git-pull  master

This will get the updates in the master branch and merge them the local_branch.

Now that we have an updated tree, let's check if our patches have been applied, we just issue:

$ git-cherry master 

If is there any un-pushed commit, it will print the commit id.

That's all for today. Next post we're gonna play a bit with git-config before keep going with patch management.

See y'all

VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)

Formating and sending patches away

Wednesday, July 4th, 2007

Hello everybody,

How to format patches and send them away?
It's just a couple of commands. Let's see how?

First of all you need to commit local changes to your local development branch. So let's do it:

$ git-status$ git-add   ... 

Now, we need to check out the logs:

$ git-log

And get the commit id just before our first commit. And then we type:

$ git-format-patch -o patches_to_send  .. HEAD

This will put all our patch series into patches_to_send/ directory. Now we can send them away.
Just issue:

$ git-send-email --to list@domain.com \--from "My Name " patches_to_send

This will send all the patches in patches_to_send/ directory.

In the next post, we're gonna learn to update our tree (and all our local branches) and track our pending patches.

See y'all

VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)

Branching: the power of git

Monday, July 2nd, 2007

Hello everybody,

Let's study a bit of how to branch with git.
This is probably one of the best features in git: the ability to create local branches and track them with upstream branch.

For instance, you can have how many branches you want. Let's say you're a maintainer of a driver, so you could use the following branches:

  • master (the upstream branch);
  • maintenance (used for maintenance tasks);
  • experimental (used for experimental work);

Ok. Now that's our scenario. Let's create those branches to see what happens:

$ git-branch maintenance
$ git-branch experimental

Now, if you run git-branch without any parameter, you will see both branches created:

$ git-branch
experimental
maintenance
* master

The "*" in master, tells you that you're now working on that branch, any changes will be committed to it.
If you mis-spelled a branch name you can rename it with git-branch -m oldbranch newbranch. Let's try it out:

$ git-branch -m experimental blabla
$ git-branch
blabla
maintenance
* master
$

It works just fine. Put back the name experimental and let's keep going.
We already how to create and rename a branch... But and if I wanna delete it? It's also really easy:

$ git-branch -d experimental
Deleted branch experimental.
$ git-branch
maintenance
* master
$

Recreate the branch experimental and let's prepare for other post. We're gonna learn how to start editing a branch, committing and merging.

See y'all

VN:F [1.9.0_1079]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.0_1079]
Rating: 0 (from 0 votes)