I started using Git a few years ago, and to be sure, I cannot say that I know everything about it. However, I know enough of it to say that I am much more efficient using Git than other source control method.

In this post, I will summarize some of the commands everyone need to know in order to start using Git.

Creating a Repository

Creating a repository is just a matter of initialize a directory with git metadata, and add the files to the repository. For example, suppose you want to create a repository of directory /home/john/myproject To do this, you need to use the commands

cd /home/john/myproject
git init
git add .
git commit -m 'first version'

The first git command just initializes the .git directory, where all git metadata is stored. The second command adds everything under the current directory to the repository. Finally, the git commit command creates the initial revision of the project into the repository.

Making Changes

The next common operation in a repository is to make changes to the existing files. After you make the needed changes using your text editor or IDE, the following commands will do the trick:

git add ChangedFile1 ChangedFile2
git commit -m 'description of change'

The git add is necessary even if the file exists, because without it git doesn’t know if the files needs to be updated or not. In git parlance, git add is used to create the “staging area”, which will be written by the commit.

This is a difference from SVN, for example, where anytime we do a commit the system accepts all changes by default. With git you need to be specific about what is being commited.

Optionally, if you prefer to use a GUI to view the changes, you can use the command

git gui

This will invoke the Tk interface, which works both on UNIX and windows (and probably Mac OS X).

Deleting and Recovering

Another common operation is to remove files. This can be done with

git rm FileName

notice that this will work if the files hasn’t been modified. If you need to delete a file that has been changed, use

git rm -f FileName

To recover a file that has been deleted or changed, you can use the following

git checkout -- FileName

Creating Branches

With the commands above you can do pretty much anything you need in terms of normal usage of a VCS. However, creating branches is where the fun is. Git favors the creation of branches, because creating them is very fast and cheap (as measured in memory usage).

To create and use a new branch, type

git branch BranchName
git checkout BranchName

The first command creates the branch, while the second changes to the new branch. You can always go back using

git checkout master

where master is the default branch name.

Merging Files

Git makes it very easy to create branches, but also to merge the results of two or more branches. To merge a branch called “BranchName”, you can use the command

git merge BranchName

Git does a great work of solving conflicts automatically. However, if it can’t solve the conflict, you will be able to edit the files manually and commit them as normal.

You can visualise the results of merges and of other branches using a graphical tool. Just type

gitk --all

and you will be able to see all branches in the repository, along with the history. For a short log of changes, you can also type

git log

Advanced Tricks

There are thousands of advanced tricks you can learn with git, since each part of the system may work independently of the others. I will give you just a flavor of what you can do.

For example, if you want to change the order in which commit appear in a branch, you can use

git rebase -i CommitID

The commit id is the hexadecimal number listed on each commit when you use git log. The command above will call an editor and allow you to edit the commits that have been made since CommitID. You can change the order in which they are applied, merge two or more commits, or even remove some of them. In this way, you can rewrite the history of your commits, and make changes that you wouldn’t be able to do in something as SVN.

Recently, I was looking at some documentation for LaTeX, specifically how the DVI format file was created. I found out that DVI was designed by a student of Knuth called David Fuchs around the end of the 70s, when the first laser printers were being designed.

The whole story of DVI design can be read on an interview by David Fuchs to tug.org. It is a fascinating description of the state of printing 30 years ago. However, the most interesting part of it is a story that shows how really good people work hard to achieve their goals:

I, of course, wrote the DVI-to-CRS software, which also required some tricky font caching (the algorithm for which is the basis of my only published paper, which was actually written by my co-author, guess who?). Those were some intense days of working together, getting it all to work. The CRS was in a cramped basement room, and I had to load and unload each sheet of photographic paper in the darkness, and feed it into the triple-bath developer. Any bug could be potentially in my code or Knuth’s firmware, and as I mentioned, debugging wasn’t easy. After a number of very long days, I came in one morning, and came into Knuth’s office just as he was arriving and handing a stack of legal paper to his secretary. “Here’s a paper I wrote, please type it in,” he told her. I was floored. We’d been working night and day; did he write the paper in his sleep?

It is not uncommon that, in the middle of an important project, you need to work extra hard. But Knuth, despite working all day to make his code work, still spent an unknown amount of time writing papers (maybe during sleep…), so he wouldn’t compromise his scientific output. It just reminds me that to be really good, it is not enough to have good ideas. You also need to work hard.

Next time you feel overwhelmed by your projects, think about this.

It only shows my academic background when I say that I use Latex for editing anything. From articles to grocery shopping lists, I like the polished result of a Latex document.

And all this started when, in school,  I started using Latex to do my homework. Sure, it used to take a little longer to have it done. But it sure looked much better than doing it by hand.

I always used vim do thinks like Latex editing, after a short period when I used Emacs + Auctex. Although Auctex is a fantastic system, with lots of nice options for Latex users, the simplicity of vim editing always struck me as the right way to do things.

In the last few days, however, I found an open source project that tries to bring many of the features of Auctex to the vim world. It is called vim-latex. From their web page [1]:

We attempt to provide a comprehensive set of tools to view, edit and compile LaTeX documents without needing to ever quit Vim. Together, they provide tools starting from macros to speed up editing LaTeX documents to compiling tex files to forward searching .dvi documents.

See the features page for a brief tour of the various features in LaTeX-suite. All these features can be tuned extensively using the included texrc file.

vim-latex has extensive support for math symbols, folding, Latex compilation, and entering Latex environments. You can compile the whole document, or just parts of it. It makes it easy to visualize what is going on, or fixing problems as they show up.

Even better, vim-latex works on Windows, so I can work on my Latex documents even when I am not working on a Linux box.

Links:

[1] http://vim-latex.sourceforge.net/

Becoming more productive is a major goal for most information workers. For this purpose, many methods have been proposed by productivity “gurus”. These methods include the well known GTD.

The reason why many of these methods don’t work is that they impose a lot of structure that helps, but that also can make life even more boring.

I think that many of these methods are overkill, so I use a simple technique that I believe is more effective. It is what I call the 5 min technique.

The first step is to classify tasks in order of importance. Your most important projects should come first. However, you shouldn’t spend too much time doing this, as you will see.

The core of the technique is to allot five minutes to work on one of your most important projects, while trying to do the most amount of work during that period.

While some people will think that the intervals of five minutes are insufficient to achieve anything useful, there are several advantages of doing this:

• Anyone can take five minutes of their time to do something. It is the same time it take to get a cup of coffee of use the restroom. However, if you use this time to do something of importance, if will add up.
• It gives you a starting point. If you started with five minutes, you could just as well work for more 10 or 30 minutes. It depends on your current schedule. Even if you can’t continue, you did something of high priority.

Using the 5 min technique is easy, and is addictive. With time, you will be continuously thinking about how to spend your next five minutes, and that is a good frame of mind. And if you don’t have a list of priorities, then you can just start now, by taking five minutes to list your most important projects and tasks.

Recently I decided to import some of my files stored on CVS repositories into Git. The idea is to make the files easier to maintain and update. Also, this way I don’t need to remember different methods to update files. Finally, it is nice to be able to use git tools such as git-gui.

The process is simple. You just need to use the git cvsimport command. This is my command line:

git cvsimport -a -v -d <location of cvsroot> -C newDir <module>

The meaning of this is as follows: the -a parameter is used to import the whole history (if you have a long history, maybe this will be slow). The -v option shows what is going on (verbose). The -d has the same meaning as on the cvs command, i.e., to show the where the root directory is. The -C option determines where the result will be stored. And finally you need to type the name of the module.

I really wanted to import all modules at the same time, but it seems that cvsimport doesn’t know how to do this. I tried to use “.” as a module name. That works with cvs to checkout everything, but cvsimport doesn’t like it. Anyway, I now can import my old files and use only git.