How to properly mirror a git repository

When people talk about mirroring a git repository, usually we have a simple answer in mind:

Just git clone the repo and you’re set!!

However, what we want with mirroring is to replicate the state of an origin repository (or upstream repository). By state, we mean all the branches (including master) and all the tags as well.

You’ll need to do this when migrating your upstream repository to a new “home”, like when switching services like GitHub.

As with most tools, there’s a lot of ways to accomplish that, but I’ll be focusing on two of them. The difference lays on whether you already have a working copy of that repository or not.

Mirroring a git repository without a local copy

If you haven’t cloned the repository before, you can mirror it to a new home by

$ git clone --mirror
$ cd upstream-repository.git
$ git push --mirror

This will get all the branches and tags that are available in the upstream repository and will replicate those into the new location.


Don’t use git push --mirror in repositories that weren’t cloned by --mirror as well. It’ll overwrite the remote repository with your local references (and your local branches). This is not what we want. Read the next section to discover what to do in these cases.

Also git clone --mirror is prefered over git clone --bare because the former also clones git notes and some other attributes.

Mirroring a git repository if you already have a local working copy

By working copy, we mean a “normal” repository, in which you have the files that are being tracked into git and where you perform commands like git add and so on.

In this case, you may have a lot of local branches and tags that you don’t want to copy to the new location. But you do have references to remote branches. You can view them with git branches -r. If you pay attention to that list, tough, you may notice that you have a lot of branches that were already deleted in the upstream repository. Why?

Cleaning old references to remote branches

By default, when you do a git fetch or git pull, git will not delete the references to branches that were deleted in the upstream repository (you may view them in your .git/refs/remotes dir). We need to clean those old references before mirroring them to a new location.

To do so, run

$ git fetch --prune

This will update your references to the origin repository and also clean the stale branches reported by git branch -r.

Finally, mirroring the repository to a new location

Now we’re ready to send those updated references back to the origin repository:

$ git push --prune +refs/remotes/origin/*:refs/heads/* +refs/tags/*:refs/tags/*

Ok, what just happened here?!

We want those references inside the .git/refs/remotes/origin to be the LOCAL references in the new location. The local references there will be stored in the refs/heads dir. Same thing happens to tags.

The + sign indicates that we want to overwrite any reference there may already exist.

--prune means we want to delete any reference that may exist there if we don’t have such reference in our refs/remotes/origin/* (and tags) references.


Git is certainly not an easy tool to learn. Although when you do, it turns into a very powerful and flexible tool.

If you want to learn more about it, please see the excelent book written by Scott Chacon and available for free.

What about you? Have any tips on git you want to share?

Install OpenProject with Docker

Docker is a way to distribute self-contained applications easily. We provide a Docker image for the Community Edition that you can very easily install and upgrade on your servers. However, contrary to the manual or package-based installation, your machine needs to have the Docker Engine installed first, which usually requires a recent operating system. Please see the Docker Engine installation page if you don’t have Docker installed.

Also, please note that the Docker image is quite new and might not support all the options that the package-based or manual installation provides.

Quick Start

The fastest way to get an OpenProject instance up and running is to run the following command:

docker run -it -p 8080:80 -e SECRET_KEY_BASE=secret openproject/community:7

This will take a bit of time the first time you launch it, but after a few minutes you should see a success message indicating the default administration password (login: admin, password: admin).

You can then launch a browser and access your new OpenProject installation athttp://localhost:8080. Easy!

To stop the container, simply hit CTRL-C.

Note that the above command will not daemonize the container and will display the logs to your terminal, which helps with debugging if anything goes wrong. For normal usage you probably want to start it in the background, which can be achieved with the -dflag:

docker run -d -p 8080:80 -e SECRET_KEY_BASE=secret openproject/community:7

Recommended usage

The one-liner above is great to get started quickly, but if you want to run OpenProject in production you will likely want to ensure that your data is not lost if you restart the container, as well as ensuring that the logs persist on your host machine in case something goes wrong.

To achieve this, we recommend that you create a directory on your host system where the Docker Engine is installed (for instance: /var/lib/openproject) where all this data will be stored.

You can use the following commands to create the local directories where the data will be stored across container restarts, and start the container with those directories mounted:

sudo mkdir -p /var/lib/openproject/{pgdata,logs,static}

docker run -d -p 8080:80 --name openproject -e SECRET_KEY_BASE=secret \
  -v /var/lib/openproject/pgdata:/var/lib/postgresql/9.4/main \
  -v /var/lib/openproject/logs:/var/log/supervisor \
  -v /var/lib/openproject/static:/var/db/openproject \

Since we named the container, you can now stop it by running:

docker stop openproject

And start it again:

docker start openproject

If you want to destroy the container, run the following commands

docker stop openproject && docker rm openproject


OpenProject is usually configured through a YAML file, but with the Docker image you need to pass all configuration through environment variables. You can overwrite any of the values usually found in the standard YAML file by using environment variables as explained in the CONFIGURATION documentation.

Environment variables can be either passed directly on the command-line to the Docker Engine, or via an environment file:

docker run -d -e KEY1=VALUE1 -e KEY2=VALUE2 ...
docker run -d --env-file path/to/file ...

SMTP configuration

By default, the docker container will try to send emails via the local postfix daemon. However emails sent this way are more than likely to fail or end up in the spam inbox of your users. We recommend using an external SMTP server to send your emails.

A good choice is SendGrid, which offers a free plan with up to 12000 emails per month. Just sign up on the website, and once your account is provisioned, generate a new API key and copy it somewhere (it looks like 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). You can also just use your SendGrid username and password, but this is less secure.

You can then configure OpenProject with the following additonal environment variables (with SendGrid, the SMTP_USER_NAME is always apikey. Just replaceSMTP_PASSWORD with the API key you’ve generated and you should be good to go):

docker run -d \
    -e \
    -e SMTP_PORT=587 \
    -e \
    -e SMTP_USER_NAME="apikey" \

You can adjust those settings for other SMTP providers, such as GMail, Mandrill, etc. Please refer to the documentation of the corresponding provider to see what values should be used.


  • Can I use SSL?

The current Docker image does not support SSL by default. Usually you would already have an existing Apache or NginX server on your host, with SSL configured, which you could use to set up a simple ProxyPass rule to direct traffic to the container.

If you really want to enable SSL from within the container, you could try mounting a custom apache2 directory when you launch the container with -v my/apache2/conf:/etc/apache2. This would entirely replace the configuration we’re using.

  • Can I use an external (MySQL or PostgreSQL) database?

Yes. You can simply pass a custom DATABASE_URL environment variable on the command-line, which could point to an external database. You can even choose to use MySQL instead of PostgreSQL if you wish. Here is how you would do it:

docker run -d ... -e DATABASE_URL=mysql2://user:pass@host:port/dbname openproject/community:7

The container will make sure that the database gets the migrations and demo data as well.

TestDisk is powerful free data recovery software

TestDisk is OpenSource software and is licensed under the terms of the GNU General Public License (GPL v2+).

TestDisk is powerful free data recovery software! It was primarily designed to help recover lost partitions and/or make non-booting disks bootable again when these symptoms are caused by faulty software: certain types of viruses or human error (such as accidentally deleting a Partition Table). Partition table recovery using TestDisk is really easy.

TestDisk can

  • Fix partition table, recover deleted partition
  • Recover FAT32 boot sector from its backup
  • Rebuild FAT12/FAT16/FAT32 boot sector
  • Fix FAT tables
  • Rebuild NTFS boot sector
  • Recover NTFS boot sector from its backup
  • Fix MFT using MFT mirror
  • Locate ext2/ext3/ext4 Backup SuperBlock
  • Undelete files from FAT, exFAT, NTFS and ext2 filesystem
  • Copy files from deleted FAT, exFAT, NTFS and ext2/ext3/ext4 partitions.

TestDisk has features for both novices and experts. For those who know little or nothing about data recovery techniques, TestDisk can be used to collect detailed information about a non-booting drive which can then be sent to a tech for further analysis. Those more familiar with such procedures should find TestDisk a handy tool in performing onsite recovery.

How can I recover my MSQL sa Password?

Q: I recently ran across a case where a company I worked with had lost their sa password. How can I reset the sa password? Do I need to reinstall SQL Server?

A: No. In most cases you won’t have to reinstall SQL Server. If you have access to the Windows Server administrative password and Windows Authentication is enabled you can easily reset the sa password using SSMS. Simply login into the host Windows Server as Administrator then open SSMS and connect to the Database Engine using Windows Authentication. You’ll see a dialog that looks a lot like Figure 1.

Figure 1 – Connecting with Windows Authentication

After connecting you can either use SSMS or T-SQL to change the sa password. To use SSMS navigate to the Security node and then expand Logins and right click the sa login to change the Password properties like you can see in Figure 2.

Figure 2 – Changing the sa password with SSMS

Alternatively you can select New Query from the SSMS menu to open Query Editor and then run the following T-SQL query to reset the password for the sa login.

USE [master]

That’s all pretty easy but what if you don’t have access an account that isn’t included in the sysadmin role? Fortunately, beginning with SQL Server 2005 members of the Windows Administrators group can access SQL Server in single-user mode. This allows you to add a login to the sysadmin role which you can then use to start SQL Server with administrative rights. The account needs to be a member of the local administrators group.

To start SQL Server in single-user mode add the parameter -m at the command line. The easiest way to do this is to use Configuration Manager. Stop the SQL Server Instance you want to change. Right click the instance to open the Properties dialog and click the Startup Parameters tab. Enter  –m in the Startup parameters option


Figure 3.

Figure 3 – Setting SQL Server to start in single user mode

Next, start the SQL Server Instance. Then open an elevated command prompt and enter sqlcmd. In the sqlcmd windows enter a command like you see following to add your login to the sysadmin group.

EXEC sp_addsrvrolemember ‘CONTOSO\mikeo2’, ‘sysadmin’;

This example adds the account CONTOSO\mikeo2 to the SQL Server sysadmin role. Next, use Configuration Manager to stop the SQL Server services and remove the -m from the Startup Parameters. Then restart the SQL Server service. You should be able to login with sysadmin rights using the account you added. Then you change the sa password using one of the techniques presented earlier.

For more information check out Connect to SQL Server When System Administrators Are Locked Out. Aaron Bertram also provides an effective alternative solution using PSExec at Recover access to a SQL Server instance.

Office 16 Click-to-Run Extensibility Component 64-bit Registration prevents Office 365 32-bit installation

Hi there,

How can I manually remove Office 16 Click-to-Run Extensibility Component 64-bit Registration?

I removed office 365 by following

and that is still not enough.

now I cannot reinstall it because of Office 16 Click-to-Run Extensibility Component 64-bit Registration

Thank you,


Hi Robert,

To completely uninstall your Office applications, we suggest you use the “easy fix” tool from this article.

To uninstall Office 16 Click-to-Run Extensibility Component 64-bit Registration, please try the steps below:
1. Press Win + R to open the Run window, type “installer” and click Enter to open the folder in File Explorer.
2. Add the column “Subject”. Right click the column headers, then click More and select Subject
3. Sort on the Subject column and scroll down until you locate the name “Office 16 Click-to-Run Extensibility Component 64-bit Registration”.
4. Right click the MSI file and choose uninstall.