NVIDIA CUDA disable/enable ECC

Show ECC config nvidia-smi -r
Enable ECC on GPU 0: nvidia-smi -g 0 -e 1
Disable ECC on GPU 0: nvidia-smi -g 0 -e 0

You need a reboot to get settings active

EMACS: Whitespaces

Motivation:
Each and every editor handles whitespaces tabs etc. differently. The first step to get everyting out to the open is so show whitespaces and tabs the way the editor sees them. For me it's emacs and the following lines in your ~/.emacs should give you a good view of whitespaces.
Look at this documentation for all references

Please be patient and drop me a comment if there are any errors or misunderstandings. I'm really no emacs pro!!!

(require 'whitespace)
(global-whitespace-mode t)

GIT: Remote branches

Show remote branches:
git remote show origin

GIT: Pushing a new repository to a git server the first time

Scenario:
You created some local repository and worked on that for a while. Now you want to have it on a server so that others can collaborate.
We want to keep the full history so we want to push the current repository to the server. In order to do this at least for the master branch you have to edit the config file at:
/.git/config
It probably looks like the following:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true


The easiest way to get everything right is to check out the empty repository from the server via git clone and diff the two config files.
Finally you see that you have to add something like:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = user@yourgitserver.com:MyNewProject
[branch "master"]
remote = origin
merge = refs/heads/master

To the existing config.

Now issue a git push origin master and the master will be pushed.
If you know whether that works with branches as well or how to get that working, please drop me a comment!?

There are other ways to just give the repository as a argument at the git push command but I like to keep my old directories.

GIT: Merging changes of a branch back to master

You branched out for development and now it is time to get the improvements back to the master branch.
This is achieve by git merge while on the master branch.

To be sure to not mess up anything, I prefer to clone my repository first and do the merge there.
So best is if you commit all changes in master and dev branch. Do a couple of pushs and pulls so everything is in sync and then clone your repository to a new location.
You can directly clone the branch you want to merge then proceed to 2. otherwise do a

• git checkout branchname


• git checkout master


• git merge branchname

You have to resolve any conflicts in any files by removing the spiky brackets in the file and of course take a close look what caused the conflict and fix it.
Then add the file via git add and commit it via git commit .
Do this for every file.

CVS: Get new directories of the server

If you want to update your CVS working copy to get new directories from the server, a simple cvs up does not get these directories.
Try cvs up -d

Hochwasser am Obermain

Höher als gedacht!

GIT: Creating a local Repository

Till now all my posts concerned repositories already created. But how to create your own git rep in the first place?
Simply execute:


mkdir new-rep-dir
cd new-rep-dir
git init-db

and the new-rep-dir is a git repository

Hint by TZ: git init is the alias for git init-db

GIT: Working on Branches: Sharing files and commits

Motivation:
You have several development branches but basically use the same files to test or benchmark all versions. Then there is no sense in developing different code in all these branches for the same purpose.
You can easily merge single files from one branch to the other by cherry-pick.

Example:
1. First commit a file and only the file you want to share, nothing else:
git commit bench.sh -m"Newest fancy script which does all tests for all versions"
2. Save the key somewhere.
3. Go to the other branch folder or checkout the other branch in the same folder, as you like.
4. git cherry-pick 123784hash

You should now have the same file in the other branch as well.


Thanks to Markus for pointing me towards this.

GIT: Tagging

Tags are nothing else then names for certain revision.
So called annotated tags store the status of the project at a specific point in time for future use.

Create a tag:
git tag -a v1.0 -m"Your comment for version 1.0"

Push tag to repository:
git push --tags