virtualenvwrapper configuration

There are files for hooks and configuration is very straight forward.
I’d like to create a new folder named src for storing all the code base. Then, change directory to the new folder. Let’s see what I can do.

There is postrmvirtualenv file under $WORKON_HOME. In my case, it is ~/venv.
Let’s open up the file in vi editor and add some hooks.

$ vi ~/venv/postrmvirtualenv

# Add following to the file and save.
path=$VIRTUAL_ENV/src
mkdir $path
cd $path

I’ve created a variable for the path of the source folder I mentioned. Then, create it and change directory to it.

Now, mkvirtualenv command lets you to create a new virtual env box and create a new folder called src under the project just created and change directory to the folder.

Let’s make some changes for workon command same as above.

I’d like to change directory to the src folder under the project once the project has been activated. Also, I’d like to change directory to the virtualenv root folder ~/venv once the project has been deactivated.

Open up postactivate and add below for activate behavior.

cd $VIRTUAL_ENV/src

Open up postactivate and add below for activate behavior.

cd $WORKON_HOME

That’s it and enjoy.

git setup with multiple keys(accounts)

I had 2 accounts in gitlab.com and I couldn’t use one rsa key to access both accounts. It seems like gitlab’s restriction.

So, I needed to create another key for the 2nd account. Let’s try.

  1. Generate a new key
    $ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
    Generating public/private rsa key pair.
    Enter file in which to save the key (/Users/myid/.ssh/id_rsa): /Users/myid/.ssh/new_rsa
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /Users/myid/.ssh/new_rsa.
    Your public key has been saved in /Users/myid/.ssh/new_rsa.pub.
    
  2. Update ssh config file
    $ vi ~/.ssh/config
    Host gitlab-com-new
      HostName gitlab.com
      User git
      IdentityFile ~/.ssh/new_rsa
    
  3. Add the new key created to ssh agent
    $ ssh-add ~/.ssh/new_rsa
  4. Add or update the git repository path
    $ git remote add origin git@gitlab-com-new:new_id/new_repository.git
    # or if the repository already exists
    $ git remote set-url origin git@gitlab-com-new:new_id/new_repository.git
  5. Enjoy 😛

ignore certain files(types) from git diff

Sometimes it’s silly when reviewing the code change from git diff command which is a simple way to see the differences between the codes from the previous and the updated and the commit contains a large css file. Actually I use less for generating css, so I don’t really need to open up and see the css file. Anyways, you can ignore any file you want from git diff. Here’s how.

You can create a .gitattributes file in the root of the repo. Inside that file, you can now exclude certain files/types from the git diff command just like the way of excluding files from .gitignore:

path/to/file.binary -diff
path/to/files/*.css -diff

.git push behavior

Git 2.0 the default behavior will be to only push the current branch checked out. The option is currently a setting called simple for option push.default.

So you can set this new (in my opinion better) default behavior right now.

Just run 

$ git config --global push.default simple

and that’s it. Just in case you want to use that. The old default, that pushed everything at once just in case you want to go back was matching, instead of simple.

.git commit messages best practice

  1. Always have a first line that references the ticket number using # notation.
  2. Blank space for the second line
  3. Additional comments after this in whatever format is best.

For example:

Fixed feature X by reticulating splines. re #1234

  • Reticulated spline for module Y and Z.
  • Small other fixes.
  • Fixed syntax and unit test issues.

Git treats the first line in a special way, especially for its summary reporting tools. We’re writing scripts using these tools. For example, to see which ticket numbers were completed in what branch, we are grepping the output of git log –pretty=oneline and having that info there would be really great.

Some examples of reasons why this is a good idea: (quoted from this blog post)
git log –pretty=oneline shows a terse history mapping containing the commit id and the summary
git rebase –interactive provides the summary for each commit in the editor it invokes
if the config option merge.summary is set, the summaries from all merged commits will make their way into the merge commit message
git shortlog uses summary lines in the changelog-like output it produces
git format-patch, git send-email, and related tools use it as the subject for emails
reflogs, a local history accessible with git reflog intended to help you recover from stupid mistakes, get a copy of the summary
gitk has a column for the summary
GitHub uses the summary in various places in their user interface

List all the files in a git repository

If you want to list all files for a specific branch, e.g. master:

$ git ls-tree -r master --name-only

OPTIONS:
-d Show only the named tree entry itself, not its children.
-r Recurse into sub-trees.

You can specify HEAD instead of master to get the list for any other branch you might be in.

If you want to get a list of all files that ever existed:

$ git log --pretty=format: --name-only --diff-filter=A | sort -