Working with both Git and Mercurial made me realize there are some really nice features one has and the other one does not; or are just not enabled by default. Following is a short description of four things making my daily work easier, making the behaviour and output very similar with both.

Pager

Git has a pager enabled by default, to have the same behaviour in Mercurial as well, PagerExtension needs to be enabled by setting following lines in .hgrc file:

[extensions]
pager = 

[pager]
ignore = version, help, update
pager  = LESS='FSRX' less

Stash/Shelve

Although I am using stash mostly with Git, I do miss it in Mercurial from time to time. Sadly ShelveExtension is not distributed with Mercurial, but only one additional step is required. You need to download hgshelve.py and put it somewhere on your file system. After that, add following two lines to .hgrc file and you are all set:

[extensions]
hgshelve = /path/to/hgshelve.py

Colours

Neither have coloured output enabled by default, to enable default ones in Git, add following lines to .gitconfig:

[color]
        diff   = auto
        status = auto
        branch = auto
        ui     = true

Not sure why, but default Mercurial colours are not very useful for me. Therefore I am using Git's scheme, lines to be set in .hgrc are:

[extensions]
color =

[color]
status.modified = cyan
status.added    = green
status.removed  = red
status.deleted  = blue bold
status.unknown  = magenta
status.ignored  = black bold

Aliases

Mercurial knows how to deal with short commands, running hg status or hg st is the same. Git is not as smart out of the box, but by defining aliases in .gitconfig file, the same short commands for all of us lazy people are available. Basic commands for every day use:

[alias]
        co = checkout
        ci = commit
        cm = commit -m
        st = status
        br = branch

tl;dr

Well, you should :)

When there is talk about security, Helen Keller's quote comes to mind:

Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing.

No matter how hard I try following these words, there are still some areas where it is wise to think a bit more on properly handling security issues; password handling being one.

Even though logic dictates not to store passwords unencrypted, there are still many cases, even recent ones, where logic is not the first priority. Few years ago, working on a large scale international project, there was a high priority request to hash passwords using 2-way hashing algorithm since MD5 was not secure enough any more. Few weeks later, after a lot of debating, the client agreed to 1-way algorithm. Sadly, there was no time to implement it properly due to the lack of time, so even today MD5 is used. Less talking, more working, perhaps?

If you have not yet, I strongly recommend reading Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes by Thomas Ptacek, which was published around the same time as the above requirement was active. Two years later, Coda Hale explained good encryption is not enough in a short lesson in timing attacks. Just imagine what will be discovered few years from now?

tl;dr

Long story short, following above guides, I have written a simple PHP bcrypt wrapper class and put it up on GitHub. See README for requirements and basic usage, feel free to fork it and use it.