mwhite

"""
Outputs history with bash and git aliases expanded.
"""
from __future__ import print_function

import re
from subprocess import check_output

BASH_ALIASES = {}
for line in check_output('bash -i -c "alias -p"', shell=True).split('\n'):

mwhite

The Ultimate Git Alias Setup

If you use git on the command-line, you'll eventually find yourself wanting aliases for your most commonly-used commands. It's incredibly useful to be able to explore your repos with only a few keystrokes that eventually get hardcoded into muscle memory.

Some people don't add aliases because they don't want to have to adjust to not having them on a remote server. Personally, I find that having aliases doesn't mean I that forget the underlying commands, and aliases provide such a massive improvement to my workflow that it would be crazy not to have them.

The simplest way to add an alias for a specific git command is to use a standard bash alias.

# .bashrc

mwhite

#!/bin/bash

# subtree merge with branches

rm -rf commcare-hq core-hq
git clone git://github.com/dimagi/commcare-hq.git
git clone git://github.com/dimagi/core-hq.git

cd core-hq

mwhite

#!/bin/bash

# git subtree merge one repo into another, copying all branches in the source
# repo to the destination repo, with the source repo's name added as a prefix
# to the branch name in the destination repo

# with handling of weird edge cases in subtree merge

# See http://git-scm.com/book/ch6-7.html for an overview of git subtree merge

mwhite

DBNAME="foodb"

# This script installs dependencies for CommCare HQ on Ubuntu 12.04 (Java,
# Jython, couchdb, couchdb-lucene, less, uglifyjs, and various python packages)
# and sets couchdb and couchdb-lucene up to automatically run on startup.  It
# also creates postgres (user 'django', pass 'django') and couchdb databases
# named according to $DBNAME as specified above. 

# Before running, you must download the following files to the script's
# directory: 

mwhite

(function foo(x) {
   return function bar() {
      alert(x);
   };      
})("foo");

(function foo(x) {
   return function bar() {
      alert(x);
   };      

mwhite

<?php

/**
 * If you use different databases for development and production, it can be tedious to maintain 
 * propel configuration and database schema files in version control, because you need to change the
 * database name and re-run propel-gen after pulling so the propel base objects refer to the correct
 * database.
 * 
 * This behavior allows you to specify a constant that will be defined when propel is loaded and
 * which will be used as the database name in the generated Peer and Query classes instead of a