One of the functions of Git that I still struggle with is merging. Recently, I found a post that shows a number of very helpful merging examples. If you work with Git and don’t fully understand merging, I recommend that you check it out.

Git merging by example

My thanks to Jonathan Rockway on providing this great guide.

UPDATE (28 Apr 2008): So apparently this article made it to the front page of delicious, reddit, and hacker news. It’s always the ones I least expect Anyway, I’ve updated the branch names to be less confusing, and I’ve added an explanation of why I say git ci instead of git commit; I have the following section in my .gitconfig file:

[alias]
st = status
di = diff
co = checkout
ci = commit
br = branch
sta = stash

This lets you type git [the left side] and allows git to interpret it as git [the right side]. A very useful feature.

We now bring you the actual article:

I’ve always liked git’s merging algorithm, so I thought I’d show an example where it works exactly like I’d expect.

Let’s get started by creating a new git repository and project:

$ mkdir git-test
$ cd git-test
$ git init

Then we’ll create a file to play with, test.pl:

#!/usr/bin/env perl

print “Hello, world.\n”;

__END__

And commit that:

$ git add test.pl
$ git ci -m ‘initial import’
Created initial commit 219c5b3: initial import
1 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 test.pl

At this point, we want to create a branch so we can refactor this mess without ruining the working code.

$ git co -b refactor
Switched to a new branch “refactor”

Now that we’re on the refactor branch, let’s sequester the print statement into a subroutine.

#!/usr/bin/env perl

say_hello();

sub say_hello {
print “Hello, world.\n”;
}

__END__

And commit:

$ git ci -a -m ‘factor print into a subroutine’;
Created commit 518dec1: factor print into a subroutine
1 files changed, 5 insertions(+), 1 deletions(-)

I have an idea for a new UI feature, so I’m going to make a branch here, but not switch to it, since I want to add another feature on this refactor branch first.

$ git branch new-ui

While we’re still on refactor, let’s get rid of that ugly \n:

#!/usr/bin/env perl
use 5.010;

say_hello();

sub say_hello {
say “Hello, world.”;
}

__END__

(Note to the non-perl-users; we added use 5.010 to pull in the new say feature. Unfortunately the program now depends on perl 5.10 instead of perl 5.anything.)

Much cleaner. Commit.

$ git ci -a -m ‘use say instead of print’
Created commit 518dec1: use say instead of print
1 files changed, 2 insertions(+), 1 deletions(-)

OK, with that braindump saved, let’s go over to the new-ui branch:

$ git co new-ui
Switched to branch “new-ui”

Now let’s add that super cool feature, namely printing “Hello, world” three times instead of just once. You think the boss will go for this change before converting all the servers to Perl 5.10, so you add it on this branch that doesn’t require 5.10.

#!/usr/bin/env perl

say_hello();
say_hello();
say_hello();

sub say_hello {
print “Hello, world.\n”;
}

__END__

Let’s commit that.

$ git ci -a -m ‘say hello three times’
Created commit affad78: say hello three times
1 files changed, 2 insertions(+), 0 deletions(-)

The unfortunate part is that management hasn’t approved that UI change, and they haven’t let you upgrade your production server to 5.10 yet. So you switch back to master to work on a task that needs to be done immediately — adding some documentation.

$ git co master
Switched to branch “master”

And then edit the file:

#!/usr/bin/env perl

print “Hello, world.\n”;

__END__

=head1 NAME

test.pl – say hello to the world

=head1 SYNOPSIS

perl test.pl

And commit:

$ git ci -a -m ‘add docs’
Created commit 80d2bba: add docs
1 files changed, 7 insertions(+), 0 deletions(-)

With all that productivity, you feel you’ve earned a sugary cup of coffee, so you head over to Caribou, buy one, and come back. You check your e-mail and find that the UI team loves your “say hello 3 times” change. So, let’s merge that into master:

$ git pull . new-ui
Auto-merged test.pl
Merge made by recursive.
test.pl | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)

Your file looks like this now:

#!/usr/bin/env perl

say_hello();
say_hello();
say_hello();

sub say_hello {
print “Hello, world.\n”;
}

__END__

=head1 NAME

test.pl – say hello to the world

=head1 SYNOPSIS

perl test.pl

If you do a git log, you’ll see that git adds each change you merged in into the history:

commit a6d16af596b2d122f4348ded85ca14a74b6adaae
Merge: 80d2bba… affad78…
Author: Jonathan Rockway
Date: Sun Apr 27 05:35:16 2008 -0500

Merge branch ‘new-ui’

commit 80d2bba051c525257aa4930b362dbe01d6c280fe
Author: Jonathan Rockway
Date: Sun Apr 27 05:34:03 2008 -0500

add docs

commit affad78861d53900199860e60b44fb5c500791f5
Author: Jonathan Rockway
Date: Sun Apr 27 05:28:02 2008 -0500

say hello three times

commit 518dec18167d36f6f7813b3affc0e76ad9baf2d9
Author: Jonathan Rockway
Date: Sun Apr 27 05:20:52 2008 -0500

factor print into a subroutine

commit 219c5b3a580c0d5d4453e118b7a9c40efb6cd13b
Author: Jonathan Rockway
Date: Sun Apr 27 05:15:39 2008 -0500

initial import

Now you’ve found out that every copy of Perl 5.8 has been destroyed (blame the sunspots), and you’ll have to upgrade to 5.10. Because of that, you can merge in your 5.10 branch. Lucky break! One thing to lose hair over, though, is that the new-ui branch that you just merged in has some commits in common with the refactor branch you’re about to merge in. Will git try to apply that change twice? (No.)

Let’s try it:

$ git pull . refactor
Auto-merged test.pl
Merge made by recursive.
test.pl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

As expected, it worked perfectly. Here’s the final file:

#!/usr/bin/env perl
use 5.010;

say_hello();
say_hello();
say_hello();

sub say_hello {
say “Hello, world.”;
}

__END__

=head1 NAME

test.pl – say hello to the world

=head1 SYNOPSIS

perl test.pl

If you look at the log, you’ll see that git knows exactly what changes were included by the merge:

commit 1d4a7814c29678d8ce69d7e241dcb21c4e5d1b88
Merge: a6d16af… d35db62…
Author: Jonathan Rockway
Date: Sun Apr 27 05:44:20 2008 -0500

Merge branch ‘refactor’

commit a6d16af596b2d122f4348ded85ca14a74b6adaae
Merge: 80d2bba… affad78…
Author: Jonathan Rockway
Date: Sun Apr 27 05:35:16 2008 -0500

Merge branch ‘new-ui’

commit 80d2bba051c525257aa4930b362dbe01d6c280fe
Author: Jonathan Rockway
Date: Sun Apr 27 05:34:03 2008 -0500

add docs

commit affad78861d53900199860e60b44fb5c500791f5
Author: Jonathan Rockway
Date: Sun Apr 27 05:28:02 2008 -0500

say hello three times

commit d35db62f2a628687db8ab2e5759cae35cffb5ab0
Author: Jonathan Rockway
Date: Sun Apr 27 05:23:45 2008 -0500

use say instead of print

commit 518dec18167d36f6f7813b3affc0e76ad9baf2d9
Author: Jonathan Rockway
Date: Sun Apr 27 05:20:52 2008 -0500

factor print into a subroutine

commit 219c5b3a580c0d5d4453e118b7a9c40efb6cd13b
Author: Jonathan Rockway
Date: Sun Apr 27 05:15:39 2008 -0500

initial import

Even though you’ve merged these branches into trunk, you can still work on them:

$ git co new-ui
$ git rebase master

rebase will merge master into the current branch, but it works by deleting your commits, bringing in master’s commits, and then replaying yours on top. This avoids the useless “merge branch ‘foo’” commit, but at the cost of being unable to share your changes with another repository (since the commit ids will change; commit ids are dependant on history, and rebase rewrites history).

The usual use case for rebase is when you’re working on a feature that takes a few days to write and want to bring in upstream every day. Instead of polluting your feature branch with merges, you can rebase and nobody will ever know that your changes weren’t originally made against today’s upstream branch. (If there are conflicts, git will allow you to resolve them for each of your patches, and it will remember how you resolved them in case the same thing comes up when you rebase again tomorrow. See git rerere –help for details.)

Anyway, after the rebase, our new-ui branch is now up to date with respect to master. If you made some changes here, you could merge them into master without issue.

Let’s do one more example; we’ll see how to merge two branches at once. We’ll switch back to master, and make a doc-refactor branch, since your app really needs more docs.

$ git co master
Switched to branch “master”
$ git co -b doc-refactor
Switched to a new branch “doc-refactor”

Here, we’ll add some POD to the end of the file:

__END__

=head1 NAME

test.pl – say hello to the world

=head1 SYNOPSIS

perl test.pl

=head1 HISTORY

As of version 0.01, C now prints “Hello, world.” three
times, for maximum enjoyment.

This isn’t quite perfect yet, but let’s commit it.

$ git ci -a -m ‘explain the 3x feature’
Created commit 80920ac: explain the 3x feature
1 files changed, 5 insertions(+), 0 deletions(-)

Meanwhile, a critical bug was just discovered — a user paused too long while reading the comma in “Hello, world.”, so you need to remove it. We’ll branch off master, since this complicated fix may take a few days of testing to fully implement:

$ git branch comma-bug-fix master
$ git co comma-bug-fix
# fix it
$ git ci -a -m ‘fix the comma bug’
Created commit 053413e: fix the comma bug
1 files changed, 1 insertions(+), 1 deletions(-)

That was easier than expected. Since the bugfix was pretty simple and your docs are done, you’re ready to share both of those changes with your coworkers by merging them into master:

$ git co master
$ git pull . comma-bug-fix doc-refactor
Trying simple merge with 053413e7fc2935cfe54de74178f493b7965081b3
Trying simple merge with 80920ac16ad72d8714b4e767a09e1f8ce974fe5a
Simple merge did not work, trying automatic merge.
Auto-merging test.pl
Merge made by octopus.
test.pl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

I love the “Merge made by octopus” message; I am seriously going to have a t-shirt made that says that. I like it when sea creatures help maintain my code.

Finally, if you don’t need those branches anymore, you can blow them away:

$ git branch -d refactor new-ui comma-bug-fix doc-refactor
Deleted branch refactor.
Deleted branch new-ui.
Deleted branch comma-bug-fix.
Deleted branch doc-refactor.

Git will only delete branches that are completely merged into the current branch, so you don’t need to worry about losing data.

In conclusion, git makes non-linear development easy. It’s smart, so merges Just Work; worrying about branches is not something you need to do anymore. Additionally, if you are the visual type, try running gitk –all. It will draw an interactive graph of all your merge and branch points, so you can see where your branches are at-a-glance. It’s awesome.

I had fun writing about how I work with Git yesterday. I thought I’d continue on that thread.

I have a solid set of code libraries that I’ve written that latch into the WordPress themes we produce at iThemes. Each time code is duplicated across different repositories, I break that code out and make it into a separate repository. I then link it back into the project as a submodule. This makes it extremely-easy to keep duplicated code across numerous repositories updated with little or no fuss.

After cloning a repository, simply run git submodule init followed by git submodule update in order to initialize all the submodules and update their container folder with the content of the submodule’s repository. For a long time, this is exactly what I did when I would clone a theme repository to start working on it. However, this quickly wasn’t enough.

The problem happened as soon as I added a submodule to a repository that was also a submodule of other repositories. Doing the submodule init and update process wouldn’t do everything I needed in this case as there would be submodules in some subfolder that haven’t been set up.

I didn’t want to get into a habit of always switching to other directories and doing the submodule processes there as well since I 1) knew that I would forget all-too-often, thus wasting my time, and 2) knew that this would not be the last time that a submodule had submodules. Heck, there is even the possibility that I’ll have a submodule that has a submodule that has a submodule. It was immediately clear that I needed a script to do all this dirty work for me. The rest of this post will be about the script I created.

The Script

First, I’ll share the script itself. If you are interested in how it works, continue reading.

git-submodule-recursive-update (right-click > “Save Link As…” to download)

The script is written in Perl and should work on most systems. I’ve only tested it on Linux and OS X, so please let me know your results if you try out on Windows.

#!/usr/bin/perl

use strict;
use Cwd;

init_and_update();

exit;

sub init_and_update
{
    my $start_path = cwd();

    my %paths;
    my $updated;

    do
    {
        my $data = `find . -name '.gitmodules'`;
        chomp($data);

        $data =~ s/\/\.gitmodules//g;

        foreach my $path (split(/\n/, $data))
        {
            $paths{$path} = '' if($paths{$path} eq '');
        }

        $updated = 0;

        foreach my $path (sort keys %paths)
        {
            if($paths{$path} eq '')
            {
                chdir($path);
                `git submodule init 2>&1`;
                `git submodule update 2>&1`;
                `git submodule foreach 'git checkout master' 2>&1`
                chdir($start_path);

                if($ARGV[0] eq '--remove-gitmodules')
                {
                    unlink("$path/.gitmodules");
                }

                $paths{$path} = 1;

                $updated++;
            }
        }
    } while($updated);
}

The Description

The functionality should look very straight-forward to anyone that knows Perl.

1. I store the current directory in the $start_path variable in order to always know where home is.
2. I start a wrapper loop that keeps running until all the possible submodules are initialized and updated.
3. Using the find command, I look for all the instances of .gitmodules and store the results in $data. The .gitmodules file exists if a repo has submodules.
4. I remove all the .gitmodules file references from the $data to leave just the paths.
5. I split the paths into an array and initialize the %paths hash to have a blank value for new paths (stored in the key). Setting this value to blank will flag the following loop that the submodules in that path have not been set up yet.
6. I create a tracker variable, $updated, to check if anything happened in the loop.
7. I then loop through the %paths hash to work on each path. If the path’s hash value is blank, I process that path.
8. I cd into the repo path, init and update the submodules, and switch back to the starting folder.
9. If the script is called with the optional --remove-gitmodules argument, I remove the .gitmodules folder while I’m focused on that folder. I use this for other automation scripts, so it may or may not be of value to you.
10. I then set the path’s hash value to 1 to flag it as done.
11. Closing out the loop, I update the $updated variable to show that something was updated in this pass.
12. Finishing up the do loop towards the top, I have while($updated). Basically, as long as something was updated in the core update loop, I’ll run everything again. This means that the loop will keep running until it didn’t find anything else that needed to be updated. When that point is reached, the main loop ends, and the script is finished.

I know that there are a number of things I could have done to make for a much more brief, compact script, but I was going to quick production with solid functionality, not brevity. In addition, there are unnecessary elements such as incrementing the $updated variable rather than just setting it to some value. I thought might want to know how many things were updated at some point, so I left it as a counter.

If you found this script helpful, please leave a comment. The more interest these Git-related posts receive, the more motivated I’ll be to share other processes, developments I’ve made to make working Git easier.

All of the WordPress themes that I work on for iThemes are managed as Git repositories. Recently, we moved past the 100 repositories mark. That’s a lot of repositories to manage, and unfortunately, too many of those repositories contain duplicated information.

Later on, I might delve into how we use Git to manage our theme repos. For today, however, I’d like to focus on how I quickly and easily pushed up changes to more than a dozen repos in a single, albeit long, Bash command.

I had finished making updates to 16 Flexx repos, and I needed to push all of those changes up. Since I had multiple working repos in that folder, I was lucky that each of these repos began with the text “Flexx”. Also, since they are all part of the same series and need to keep the same version number, that simplified the tagging as all could be tagged as 2.5.0.

Given this information, I simply ran the following command from the directory that contained all the repository directories:

There’s a lot going on here, so I’ll break it up and explain what I’m doing.

This is basically a compound command. Bash’s for command is being used to step through the results of ls|grep Flexx. Each result will be stored to the variable i which can be referred to with $i.

In other words, I’m going to loop through each directory that contains the text “Flexx” (technically, it isn’t limited to just directories, but I don’t have any files containing “Flexx”, so I’m safe). For each iteration of the loop, the variable $i will contain the name of the folder I’m interested in.

The most important bit here is do. do simply begins the functional part of the loop and could be followed by any command that I wanted to start the loop with.

The echo command isn’t technically necessary. I simply have it there so that I can better determine what output belongs to which repository.

This is a very important command. It changes the directory to the repository I wish to run commands on.

This is the command that actually does what I want to do in each repo directory. This adds all the modified files, commits them with a message of “2.5.0″, pushes the changes to the remote repository, creates a new tag of 2.5.0, and pushes up the new tag.

I have all of these commands chained together with && so that if one command fails, the other ones won’t run. This prevents tagging in the event that the repository couldn’t be committed or pushed.

It’s a small command but necessary. This switches back to the main directory that holds all the repos, thus returning us back to a state that the next loop iteration can work with.

As with the other echo command, this simply allows me to keep track of what is going on more easily.

The done command finishes out the loop iteration.

I hope that by sharing this you can gain a bit of insight into how I work with repositories while also learning more about how you can do things with Bash.

I’ve spent a little more than a month working with Git now. I can honestly say that while there are many things that I like about Git, there are just as many things that I personally find to be a pain in the butt.

Submodules specifically have managed to be a thorn in my side on many occasions. While the concept of submodules is simple, figuring out how to actually work with them can be a chore. I say “figuring out” because not everything about working with submodules is well documented. I’ll cover two of the more difficult things to figure out: removing and updating submodules from your repository.

What are Submodules?

The concept of submodules is brilliant. It essentially allows you to attach an external repository inside another repository at a specific path. In order to illustrate the value of submodules, it will probably be helpful for me to explain how I am using them.

My profession is working with WordPress themes. Basically, I develop feature enhancements to the themes. I develop the code for these enhancements in modules that are completely contained in their own folder. This allows for the code to be easily added to other themes and also simplifies code updates/improvements as the code for specific features is consistent across all the themes that use that specific module.

Each theme that we produce is kept in its own Git repository. In addition, I’ve created a separate repository for each one of these feature modules. Rather than actually putting the feature module code directly into the theme repositories, I simply add the needed feature module repositories as submodules.

For example, we have a theme called FlexxBold. FlexxBold currently includes a total of seven submodules: billboard, contact-page-plugin, featured-images, feedburner-widget, file-utility, flexx-layout-editor, and tutorials. Since I’m using submodules, the code can be pulled directly from the relevant submodule repositories rather than requiring me to manually update each individual theme repository.

As I mentioned before, not everything in Git is easy to work with. There are four main functions you will need to understand in order to work with Git submodules. In order, you will need to know how to add, make use of, remove, and update submodules. I’ll cover each of those uses below.

Adding Submodules to a Git Repository

Fortunately, adding a submodule to a git repository is actually quite simple. For example, if I’m in the repository working directory of a new theme called SampleTheme and need to add the billboard repository to the path lib/billboard, I can do so with the following command:

[user@office SampleTheme]$ git submodule add git@mygithost:billboard lib/billboard
Initialized empty Git repository in ~/git_dev/SampleTheme/lib/billboard/.git/
remote: Counting objects: 1006, done.
remote: Compressing objects: 100% (978/978), done.
remote: Total 1006 (delta 631), reused 0 (delta 0)
Receiving objects: 100% (1006/1006), 408.22 KiB, done.
Resolving deltas: 100% (631/631), done.

There are three main parts to this command:

• git submodule add – This simply tells Git that we are adding a submodule. This syntax will always remain the same.
• git@mygithost:billboard – This is the external repository that is to be added as a submodule. The exact syntax will vary depending on the setup of the Git repository you are connecting to. You need to ensure that you have the ability to clone the given repository.
• lib/billboard – This is the path where the submodule repository will be added to the main repository.

Let’s check to see how the repository is doing.

[user@office SampleTheme]$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   .gitmodules
#       new file:   lib/billboard
#

Notice how the supplied path was created and added to the changes to be committed. In addition, a new file called .gitmodules was created. This new file contains the details we supplied about the new submodule. Out of curiosity, let’s check out the contents of that new file:

[user@office SampleTheme]$ cat .gitmodules
[submodule "lib/billboard"]
path = lib/billboard
url = git@mygithost:billboard

Being able to modify this file later will come in handy later.

All that is left to do now is to commit the changes and then push the commit to a remote system if necessary.

Using Submodules

Having submodules in a repository is great and all, but if I look in my repository, all I have is an empty folder rather than the actual contents of the submodule’s repository. In order to fill in the submodule’s path with the files from the external repository, you must first initialize the submodules and then update them.

First, we need to initialize the submodule(s). We can do that with the following command:

[user@office SampleTheme]$ git submodule init
Submodule 'lib/billboard' (git@mygithost:billboard) registered for path 'lib/billboard'

Then we need to run the update in order to pull down the files.

[user@office SampleTheme]$ git submodule update
Initialized empty Git repository in ~/git_dev/SampleTheme/lib/billboard/.git/
remote: Counting objects: 26, done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 26 (delta 5), reused 0 (delta 0)
Receiving objects: 100% (26/26), 17.37 KiB, done.
Resolving deltas: 100% (5/5), done.
Submodule path 'lib/billboard': checked out '1c407cb2315z0847facb57d79d680f88ca004332'

Looking in the lib/billboard directory now shows a nice listing of the needed files.

Removing Submodules

What happens if we need to remove a submodule? Maybe I made a mistake. It could also be that the design of the project has changed, and the submodules need to change with it. No problem, I’ll simply run “git submodule rm [submodule path]” and everything will be great, right?

[user@office SampleTheme]$ git submodule rm lib/billboard
error: pathspec 'rm' did not match any file(s) known to git.
Did you forget to 'git add'?
 b8ff8f68eb56938b9b4bf993619218fa848c5848 lib/billboard (1.2.25)

Unfortunately, this is wrong. Git does not have a built in way to remove submodules. Hopefully this will be resolved in the future, because we now have to do submodule removal manually.

Sticking with the example, we’ll remove the lib/billboard module from SampleTheme. All the instructions will be run from the working directory of the SampleTheme repository. In order, we need to do the following:

1. Remove the submodule’s entry in the .gitmodules file.Since lib/billboard is the only submodule in the SampleTheme repository, we can simply remove the file entirely by running “git rm lib/billboard”.If lib/billboard isn’t the only submodule, the .gitmodules file will have to be modified by hand. Open it up in vi, or your favorite text editory, and remove the three lines relevant to the submodule being removed. In this case, these lines will be removed:
   [submodule "lib/billboard"]
   path = lib/billboard
   url = git@mygithost:billboard
2. Remove the submodule’s entry in the .git/config. This step isn’t strictly necessary, but it does keep your config file tidy and will help prevent problems in the future.The submodule’s entry in .git/config will only be present if you’ve run “git submodule init” on the repository. If you haven’t, you can skip this step.In this example, the following lines will be removed:
   [submodule "billboard"]
   url = git@mygithost:billboard
3. Remove the path created for the submodule. This one is easy. Simply run “git rm –cached [plugin path]“. In this example, I will run “git rm –cached lib/billboard“.As I’ve seen noted elsewhere, do not put a trailing slash as the command will fail. For example, if I run “git rm –cached lib/billboard/“, I get an error: “fatal: pathspec ‘lib/billboard/’ did not match any files“.

   [user@office SampleTheme]$ git rm --cached lib/billboard
   rm 'lib/billboard'

Updating Submodules

There is an aspect about submodules that some may not realize when first working with Git submodules. When you add the submodule, the most recent commit of the submodule is stored in the main repository’s index. That means that as the code in the submodule’s repository updates, the same code will still be pulled on the repositories relying on the submodule.

This makes a lot of sense when you consider how your code will have been tested and verified (or at least should be) against a specific version of the submodule code, but the main repository’s code may not work well with new submodule updates before the changes are tested.

Unfortunately, like removing submodules, Git does not make it clear how to update a submodule to a later commit. Fortunately though, it’s not that tough.

1. Initialize the repository’s submodules by running “git submodule init” followed by “git submodule update“.

   [user@office SampleTheme]$ git submodule init
   Submodule 'lib/billboard' (git@mygithost:billboard) registered for path 'lib/billboard'
   [user@office SampleTheme]$ git submodule update
   Initialized empty Git repository in ~/git_dev/SampleTheme/lib/billboard/.git/
   remote: Counting objects: 26, done.
   remote: Compressing objects: 100% (22/22), done.
   remote: Total 26 (delta 5), reused 0 (delta 0)
   Receiving objects: 100% (26/26), 17.37 KiB, done.
   Resolving deltas: 100% (5/5), done.
   Submodule path 'lib/billboard': checked out '1c407cb2315z0847facb57d79d680f88ca004332'

2. Change into the submodule’s directory. In this example, “cd lib/billboard“.

   [user@office SampleTheme]$ cd lib/billboard
   [user@office SampleTheme/lib/billboard]$ 

3. The submodule repositories added by “git submodule update” are “headless”. This means that they aren’t on a current branch.To fix this, we simply need to switch to a branch. In this example, that would be the master branch. We switch with the following command: “git checkout master“.

   [user@office SampleTheme/lib/billboard]$ git status
   # Not currently on any branch.
   nothing to commit (working directory clean)
   [user@office SampleTheme/lib/billboard]$ git checkout master
   Previous HEAD position was b8ff8f6... re-ordering
   Switched to branch 'master'
   Your branch is behind 'origin/master' by 8 commits, and can be fast-forwarded.
   [user@office SampleTheme/lib/billboard]$ git status
   # On branch master
   # Your branch is behind 'origin/master' by 8 commits, and can be fast-forwarded.
   #
   nothing to commit (working directory clean)

4. Next, we simply need to update the repository to ensure that we have the latest updates. We can do that with a pull: “git pull“.

   [user@office SampleTheme/lib/billboard]$ git pull
   remote: Counting objects: 31, done.
   remote: Compressing objects: 100% (24/24), done.
   remote: Total 24 (delta 15), reused 0 (delta 0)
   Unpacking objects: 100% (24/24), done.
   From mygithost:billboard
      b8ff8f6..5cab93f  master     -> origin/master
    * [new tag]         1.2.28     -> 1.2.28
   From mygithost:billboard
    * [new tag]         1.2.26     -> 1.2.26
    * [new tag]         1.2.27     -> 1.2.27
   Updating c547e0d..5cab93f
   Fast-forward
    billboard.php                           |  109 ++++++++++++++-
    classes/view_gettingstarted.php         |  107 ++++++++++++++
    classes/view_gettingstarted_content.php |   38 +++++
    css/admin.css                           |   26 ++++
    history.txt                             |   22 +++-
    js/admin.js                             |   17 +++
    lib/updater/get.php                     |   94 +++++++-----
    lib/updater/history.txt                 |    9 ++
    lib/updater/updater.php                 |  241 ++++++++++++++++++-------------
    9 files changed, 519 insertions(+), 144 deletions(-)
    create mode 100644 classes/view_gettingstarted.php
    create mode 100644 classes/view_gettingstarted_content.php
    create mode 100644 css/admin.css
    create mode 100644 js/admin.js
    create mode 100644 lib/updater/history.txt

5. Now switch back to the root working directory of the repository. In our example, we are two directories in, so we run “cd ../..“.

   [user@office SampleTheme/lib/billboard]$ cd ../..
   [user@office SampleTheme]$ 

6. Everything is now ready to be commit and pushed back in (if there is a remote repository to push to that is). If you run “git status“, you’ll notice that the path to the submodule is listed as modified. This is what you should expect to see. Simply add the path to be commit and do a commit. When you do the commit, the index will update the commit string for the submodule.

   [user@office SampleTheme]$ git status
   # On branch master
   # Changed but not updated:
   #   (use "git add ..." to update what will be committed)
   #   (use "git checkout -- ..." to discard changes in working directory)
   #
   #	modified:   lib/billboard (new commits)
   #
   no changes added to commit (use "git add" and/or "git commit -a")
   [user@office SampleTheme]$ git add lib/billboard
   [user@office SampleTheme]$ git status
   # On branch master
   # Changes to be committed:
   #   (use "git reset HEAD ..." to unstage)
   #
   #	modified:   lib/billboard
   #

Closing Thoughts

I’ve learned a lot in my short time with Git. Expect to see more details about working with Git in the future. I have a series of pitfalls I’ve discovered that I should organize together and post about. I’ve also created some really slick scripts to help me automate numerous things when working with the repositories that I’d like to share.

If there is anything specfic you’d like to know about Git, please add a comment or contact me.

As I mentioned before, I want to switch from using Subversion for project code collaboration and versioning to Git.

I’m switching not because I have some idealogical dread of Subversion or its methods. In fact, I quite like how much easier Subversion has made handling code collaboration. The problem I ran into is that Subversion has become doggedly slow and bloated.

For example, a simple project with a current working size of 2.9MB has a Subversion repository that is a massive 98MB in size. Furthermore, it takes a full four minutes to commit a change, even a simple one-line change to a text file. During this commit process, my server’s dual quad-core processors are essentially maxed. Why the repository has become so amazingly large and why the commits take so long, I’ll never know. The maxing out of my server for four minutes per commit is also unacceptable since there are times where minor changes will need to be made to more than a dozen repositories at a time. Multiply the number of commits by 4 minutes a piece, and not only is a terminal on my system tied up for more than an hour, but my server’s CPU is maxed for just as long.

Beginning last week, I dug into Git and learned what I needed to know. The initial impressions are great; however, Git is not without its problems either. The primary problem with Git is that its syntax is extremely-obscure, IMHO.

Subversion was my first version control system, and I only started using it a few months ago. Still, I had no problem setting up remote Subversion repositories, properly setting up read-only and write privilege rules for specific people, getting the repositories to work appropriately, writing automation scripts in Perl that linked into the hooks, and wrapping the whole deal in WordPress to allow for easy management of the repositories and quick access to archives. From my initial playing around with Subversion to having a functional system in use complete with custom code supporting it took maybe two or three work days worth of time.

My progress with Git has been much slower. You might wonder why I’m bothering with Git and not looking elsewhere then. Frankly, I have found that Git has everything I want (speed, lack of redundant file stores, hooks, etc). It also looks like Git can offer some nice enhancements to how we develop projects as branches can be used without having severe performance penalties. The only true problem I’ve found with Git so far is the relatively-large learning curve. Fortunately, I’m just about done with reading, and I’ve learned all the basics I need to know to implement a system I want.

I started with Git by jumping into the wading pool at GitHub. My experience was very good. I highly recommend using GitHub if you have a public project, a private project without specific needs, or just want to try Git out. There are a lot of options at GitHub, and they very nearly had everything I wanted. One of the main limitations at GitHub is the inability for an account to allow other accounts to make repositories for it. For many projects/companies, this won’t be a problem. For us, it is a critical issue. I want to allow certain people to create new repositories, but I don’t want to have to give them “the keys” to the main account in order to allow them to do this.

So, I’m sticking with a self-hosted solution for our repositories since I can code up a clean interface that allows anyone with commit access to create whatever repositories they need. I also gain many other customization advantages this way.

Setting up remote repositories, especially private ones with selective access can be a challenge with the tools that come with Git. In fact, they were so much of a challenge that I gave up on them. I ended up using Gitosis which supports multiple “users” that authenticate using their SSH key and allows for selective repository access for these users.

Since Gitosis doesn’t appear to have any official site, it’s use, just like Git itself, is a bit of a difficult thing to grasp. Fortunately, there are some great tutorials on getting starting with Gitosis. I recommend this Gitosis tutorial as it is the main one that I referred to in order to get everything working.

If this topic looks like it is gaining interest, I’ll probably do some follow up post with more specifics of how I set everything up, what config tweaks I used, and maybe details about my custom interfaces.

FYI: I converted that 98MB Subversion repository to Git using the git-svn tool. The same repository with all the tags and history preserved weighed in at a mere 6.9MB as a Git repository.

I’m playing around with git as a possible replacement for Subversion (svn). I’ll probably blog about my reasons for wanting to switch and also have some tutorials. For now, I wanted to quickly share the fix for a problem I encountered that wasn’t really handled by the documentation.

I set up a bare remote repository to test git out. Everything looked good as I got this going, but then I hit a big snag.

When I tried to push the local repository back to the remote repository, I received the following error:

I have to say that this was completely unexpected as I had followed tutorials in the official documentation up to this point. None of the steps said anything about a “project description file” nor about new bare repositories requiring additional setup in order to be pushed to.

Fortunately, this problem wasn’t difficult to fix. There is a file inside the bare repository’s root called description. I simply modified this file and the next time I pushed the changes, it worked like a charm.

If your bare repository is in ~/projects/test.git, you would do the following:

1. Modify the description file:
   vi ~/projects/test.git/description
2. Delete the existing text:
   Unnamed repository; edit this file to name it for gitweb.
3. Put whatever description you want for the repository in the file:
   My Really Awesome Project
4. As always, save the file and close vi.

Now you can push without this nasty error hanging you up.

As a side note, the developers of git have a hosted git solution that is really cool. It’s called github, you should check it out.