Eclipse Che Get SSH Workspace Public Key

If you are working with a source code versioning system such as or Gitlab you may need to create a private and public keypair in order to clone your repositories within your workspaces.

To achieve this you may use the following command substituting the [CONTAINER ID] for your Eclipse Che workspace instance ID.

First within the Terminal pane of your workspace generate a keypair if one doesn’t already exists using the ‘ssh-keygen’ command.

Once the keypair is created run this command from your docker host.

`$ docker exec [CONTAINER ID] cat /home/user/.ssh/`

Encrypted Remote Git Repository OSX/Linux

1. Clone the git repo



2. Install docutils

sudo pip install docutils

3. Create symbolic link
(On OSX/Mac the symbolic link will need to be created.)

sudo ln -s /usr/local/bin/ /usr/local/bin/rst2man

Web hook pull Git Repo down to a web server for production without history or .git folder

Deploying with web hook

Place a file with the line below in your web root. Have the web hook on github or gitlab call the url i.e.

This will update your web root (public_html , www) with the latest version of your code without the history and without .git folder.


`git archive –format=tar – master | tar -xf -`



Alternate method 

Deploying a Git repository to a remote server

Git’s archive command is basically the equivalent of SVN’s export – it dumps a copy of the entire repository without any of the version control files, making it perfect for deploying to a testing or production server.

Using a combination of git archive, SSH, and Gzip; deploying a Git repository to a remote server can be done quickly and easily:

git archive --format=tar origin/master | gzip -9c | ssh "tar --directory=/var/www -xvzf -"

Let’s take a look at the different parts of that command.

This tells Git to combine all of the repository’s files into a single tarball file. The benefit of doing this is that a large single file can be transferred much quicker than thousands of smaller files.

If you are familiar with Git, you should recognise that these are the default names for a Git remote and branch. You should change these to match your remote/branch setup.

gzip -9c
The tarball created by git archive is piped into Gzip, which applies compression to reduce the size of the file. The 9 flag tells Gzip to use the best compression method, and the c flag makes Gzip write the compressed file to stdout. The reason we want Gzip to write to standard output is so that we can send the compressed repository straight to the remote server via SSH.

ssh “tar –directory=/var/www -xvzf -“
The Gzipped tarball is then piped through SSH to your remote server. The remote server runs tar --directory=/var/www -xvzf - which extracts the Gzipped tarball into the /var/www directory. Note that the hyphen (-) at the end of the tar command tells tar to receive data from a piped command instead of a file.

Creating a Git within a Git – aka, the Russian doll git


Using Felix’s technique works great.

Git submodules suck. They are a pain to use, difficult to explain and you cannot check out partial trees. The later is an inherent limitation of git, but I have a fix for the rest.

Meet fake submodules. The idea is simple, instead of using actual submodules, you just trick git into thinking the files belong to the main repository while having the respective sub-dirs remain independent clones. Doing that is simple:

$ cd my-project
$ git clone <subproject-url> my-subproject
$ git add my-subproject/

The important part is the “/” (slash) at the end of the last command. If you omit that, git will automatically assume you want to add ‘my-subproject’ as a submodule. But if you don’t, git just sees the files in the sub-directory and ignores that fact that its a git-repo of its own.

The cool thing is that you can now update a fake sub-module to the latest version as simple as:

$ cd my-subproject
$ git pull

This works because when you are inside my-subproject, git uses the ‘.git’ folder closest to it which is my-subproject/.git. If the sub project is your own, you could even push your changes to it upstream without changing projects.

Now as far as collaboration is concerned, none of your collaborators will have a clue about your fake submodules. All they will see is some code in some folder. They will not be able to go into the my-subproject folder and git pull on it. However, if they need to do that, they can just rm -rf my-subproject and replace it with a clone themselves.

To me this is a pretty perfect & easy solution. I mostly use it for CakePHP plugins & node.js modules I am working on, but it works just as great with other peoples code you want to depend on. You can even apply hacks against their code, have them in your main repository, and make sure they stay applied on top by using ‘git pull –rebase’ when updating the sub project.




cleaning git repository and shrinking for size and performance



Cleaning the files

Cleaning the file will take a while, depending on how busy your repository has been. You just need one command to begin the process:

$ git filter-branch --tag-name-filter cat --index-filter 'git rm -r --cached --ignore-unmatch filename' --prune-empty -f -- --all 

This command is adapted from other sources—the principle addition is --tag-name-filter cat which ensures tags are rewritten as well.

After this command has finished executing, your repository should now be cleaned, with all branches and tags in tact.

Reclaim space

While we may have rewritten the history of the repository, those files still exist in there, stealing disk space and generally making a nuisance of themselves. Let’s nuke the bastards:

$ rm -rf .git/refs/original/ 
$ git reflog expire --expire=now --all 
$ git gc --prune=now 
$ git gc --aggressive --prune=now 

Now we have a fresh, clean repository. In my case, it went from 180MB to 7MB.

Push the cleaned repository

Now we need to push the changes back to the remote repository, so that nobody else will suffer the pain of a 180MB download.

$ git push origin --force --all 

The --all argument pushes all your branches as well. That’s why we needed to clone them at the start of the process.

Then push the newly-rewritten tags:

$ git push origin --force --tags 

Tell your teammates

Anyone else with a local clone of the repository will need to either use git rebase, or create a fresh clone, otherwise when they push again, those files are going to get pushed along with it and the repository will be reset to the state it was in before.