Creating Local Git Repositories with Sourcetree

Storing a repository locally on your hard drive sort of defeats the purpose behind Git’s design…it’s not on a remote server with timely backups, and you’re basically the only one who can access and maintain it.

That said, it is a viable solution if you happen to like using Git and you have the following reasons for doing it:

  • You’re using Windows
  • You want to version control your own code
  • You want to keep your code in your hands and not some server several hundred miles away.
  • You don’t have a convenient local area network computer to store the repository.

Surprisingly, it isn’t as difficult as most solutions make it out to be.  In fact, you do not need to run your own Git server.  All you need is a git client.  Then, using the client, you create two repositories instead of one.  And then have one repository point to the other as the remote.

You have to deal with one problem however, pushing will probably throw an error.  Git will refuse to push because the remote has a checked out branch.

There are three different solutions:

  1. Create a bare repository
  2. Create and check out a dummy branch on the remote repository
  3. Edit the configuration files to ignore this check

I’m going to cover two of them since the third one strikes me as interesting, but bad practice.  The first solution cannot be done using Sourcetree alone.  Creating a bare repository:

What is a bare repository?

Bare repository is the one that has no working tree. It means its whole contents is what you have in.git directory.

You can only commit to bare repository by pushing to it from your local clone. It has no working tree, so it has no files modified, no changes.

To have central repository the only way it is to have a bare repository.

I included the above quote to basically say that a bare .git repository is just going to have a .git folder with stuff inside.  Nothing else will be in that directory, so if you do have source code in that directory, do not be afraid if they are not being updated whenever you push.

In Git you should only use a “bare” repository to clone and pull from, and push to. It doesn’t have a checked out tree, so it just does what the “server” notionally does in a centralized VCS – records commits, branches, etc when you push to it, and gives you the latest versions when you clone or pull from it.

I suppose I should also say that I’m throwing all the above links because I saw a stack overflow comment about how online repositories like GitHub are basically bare .git repositories, but I lost the link. Or maybe I didn’t…

There are two types of repositories: bare and non-bare

Bare repositories do not have a working copy and you can push to them. Those are the types of repositories you get in Github! If you want to create a bare repository, you can use

So, in short, you can’t push to a non-bare repository (Edit: Well, you can’t push to the currently checked out branch of a repository. With a bare repository, you can push to any branch since none are checked out. Although possible, pushing to non-bare repositories is not common). What you can do, is to fetch and merge from the other repository. This is how the pull request that you can see in Github works. You ask them to pull from you, and you don’t force-push into them.

But, as said before, you cannot create a remote repository using sourcetree alone.  Converting a remote repository to a bare repository can be done using the following method:

You can simply convert your remote repository to bare repository (there is no working copy in the bare repository – the folder contains only the actual repository data).

Execute the following command in your remote repository folder:

Then delete all the files except .git in that folder. And then you will be able to perform git push to the remote repository without any errors.

As said twice before, you can’t use Sourcetree to do the above.  However, you can download and use Git from the command line to pull it off:

Which leads to our second solution…how can you push to the local (remote) repository using sourcetree?

The answer is to go to the second repository and create a dummy branch.  Then check out the dummy branch.  Now you can use the first repository to push to the second repository.

Remind me that I need to add how-to create the repositories later.


Preventing Post Resubmission

The above link had some good links inside.  I’ve attached them below:


The following link contains info on how to do it server side.

Aliases in a Select Statement

Did you know that if you define an alias when selecting columns, you probably can’t use it inside of a WHERE clause without getting an Unknown Column error?

The standard explanation given by This site ( and used by many of the sites that I found with google explains it by saying that:

Standard SQL disallows references to column aliases in a WHERE clause. This restriction is imposed because when the WHERE clause is evaluated, the column value may not yet have been determined.

I think I found a layman’s explanation for the problem here:

SQL is evaluated backwards, from right to left. So the where clause is parsed and evaluate prior to the select clause. Because of this the aliasing of u_name to user_name as not yet occurred.

And I believe a workable solution can be found here:

So…instead of using WHERE, use HAVING.

Here’s the conclusion of when to use either as found by:

Here’s the rule. If a condition refers to an aggregate function, put that condition in the HAVING clause. Otherwise, use the WHERE clause.


Here’s another rule: You can’t use HAVING unless you also use GROUP BY.

Sql Patterns

Debugging relative links in php

First I should mention that I’ve gotten good results when using the get_cwd() function.  With it, I can tell what directory I am starting from, and from there build the appropriate relative paths.

It’s simple to use.

Run the script, and you’ll know where your starting point is.

That said, beware of the register_shutdown_function().  I noticed the get_cwd() result changed while inside of this function.  I found a link with a workaround, but the gist of it is that the working directory of the script can change.

Here’s a sample you can use:

Arguments against exposing auto-incrementing numbers for SQL queries

This link had some good arguments against exposing auto-incrementing numbers on a web page.

But generally, web developers feel uncomfortable exposing IDs that allow guessing other IDs by just incrementing or decrementing a number. Many resort to random, multi-digit IDs instead.

On a more obscure note, numeric IDs may also allow competitors to estimate your growth by keeping track of how the incremental value increases.

Find the Bug!

Here’s the query to troubleshoot:

When you run the above query, you’ll get a funny message:

So where’s the syntax error?

It turns out that the parenthesis within the SET statement is a syntax error.  I’m currently not sure why the parenthesis cause problems, but you need to take them out in order to run the above query.

So, the working query would be:

Starting and Ending Transactions

Following the spirit of atomic operations, I found a link on starting and ending a transaction.

And this might be a good link for figuring out where to place the commit statement when using prepared statements.