2014-02-04

Git - how to revert multiple recent commits

Git - how to revert multiple recent commits

Let's assume we have a history like this:

G1 - G2 - G3 - B1 - B2 - B3

Where G1-G3 are 'good' commits and B1-B3 are 'bad' commits and we want to revert them. If changes are not pushed to the server yet then the easy way is to reset the state to previous commit with git reset --hard HEAD~3. Here we can refer to B3 as HEAD, B2 is HEAD~1, B3 is HEAD~2. This way the last good commit G3 is HEAD~3.

But if changes are pushed it is better to use revert. And here is how to do this for multiple commits:

$ git revert --no-commit HEAD~2^..HEAD

Or:

Git - how to keep git log output on the screen after exit

How to keep git log and less output on the screen

When git uses less as pager the output of commands like git log disappear from the console screen when you exit from less. This is not convenient in many cases so here is how to fix this.

Just for git commands:

git config --global --replace-all core.pager "less -iXFR"

For less globally (including git) - add to .bashrc / .zshrc / etc:

export LESS=-iXFR

The options we set for less are:

* -i - ignore case when searching (but respect case if search term contains uppercase letters)
* -X - do not clear screen on exit
* -F - exit if text is less then one screen long
* -R - was on by default on my system, related to colored output

Links

Linux Questions: more or less - but less does not keep its output on the screen

2013-12-02

Node.js - how to get core module source

Node.js - how to get core module source

It is possible to ask node to show its core module source. For example, we want to check the source of the readFileSunc() method:

$ node
> fs = require('fs');
> fs.writeFileSync('fs.js', fs.toString())
> fs.writeFileSync('fs.readFileSync.js', fs.readFileSync.toString())
[Ctrl-C][Ctrl-C]

Now check the fs.readFileSync.js file in the current folder.

Also on some systems source code of core node modules is in the /usr/lib/nodejs/.

And another (less interesting) way to get core module source - is to look for it in the node github repository:

Node.js - how to debug mocha test with node inspector

Node.js - how to debug mocha test with node inspector

Update: found a much better method: just run mocha with --debug and --debug-brk parameters and then open node-inspector:

$ mocha --debug --debug-brk

Old method: to debug mocha test with node inspector use the delay before test:

beforeEach(function(done) {
    //start mocha as
    //mocha -t 10000 --debug
    setTimeout(function() {
        done();
    }, 5000);
});

This way there are 5 seconds to start the node inspector and set a breakpoint. Mocha should be lauched as this:

$ mocha -t 10000 --debug

Same approach can be used not only for tests but for any short-living node app - just wrap the startup code into the setTimeout() call.

2013-10-22

Elastic Beanstalk - cron command and RDS DB access

Elastic Beanstalk - cron command and RDS DB access

Problem

I have a console command in php which needs an access to DB. The command need to be launched via cron.

The DB connection string looks like like this

'connectionString' => 'mysql:host='.$_SERVER['RDS_HOSTNAME'].';port='.$_SERVER['RDS_PORT'].';dbname='.$_SERVER['RDS_DB_NAME'],

where RDS_xxx parameters come from environment variables.

The problem is that cron launches the command in a clean environment (there are no RDS_xx variables). So the command fails to access the database.

Solution

Solution is to set the required environment variables before launching the command and this can be done with '/opt/elasticbeanstalk/support/envvars' script:

0 3 * * * . /opt/elasticbeanstalk/support/envvars; /var/www/html/console/yiic mycommand

2013-09-11

Elastic Beanstalk - deploy from different machines / by different users (or how to get rid of absolute paths in configs)

Elastic Beanstalk - deploy from different machines / by different users (or how to get rid of absolute paths in configs)

By default Elastic Beanstalk console tool (eb) adds config files to .gitignore. If there are manual changes to EB configs it can be complex to manually sync these changes between different machines / different users. Of cause it is possible to add config files to git repository but there are also several parameters in the main config which are absolute paths to local files. This way it makes configs not useful for other users (except for the case when different users have exactly the same files layout). Here is how this problem can be fixed:

  1. Add eb tools under git control
  2. Add eb configs under git control
  3. Patch eb tools to accept relative file paths
  4. Change paths in configs to relative

Below are details for each step.