If you want to create git aliases optimized for your daily work, you should start by analysing your shell logs to find out which git commands you use most of the time and create shortcuts for them:

Some time ago i stumpled over Joel Perras (@jperras) blogentry Making Git Behave on twitter, covering the .gitconfig file and that was when I first found out about gits aliases and thanks to Joel I started to fill my gitconfig with more and more of them, speeding up my work with git und my working-environment for my mostly symfony based stuff.

If you ever get this message:

RuntimeException: PHP Fatal error:  Uncaught exception 'PDOException' with message 'You cannot serialize or unserialize PDOStatement instances' in -:31
Stack trace:
#0 [internal function]: PDOStatement->__sleep()
#1 -(31): serialize(Array)
#2 -(190): __phpunit_run_isolated_test()
#3 {main}
  thrown in - on line 31

Something with a doctrine/pdo went wrong in one of your tests, but since serialize does not work on pdo-classes, it prints out only this message.
If you want doctrines/PDOs message, run only this one test with process isolation turned off and you will get the error-message.
Really bad to debug on a continous-integration-system if it fails only there :)

After using my last solution for some time i came up with some improvements. Allowing all chars can be a security and usability-problem, so I switched to use some methods Doctrine uses for its slugs now.

Using = to make a column linked to the edit-page of an entry in the symfony-admin generator.yml is ugly if an entry's column is empty, because the link_to()-helper will then use the href of the link as link text. If prefere just an empty column.

Symfonys behaviour to rename uploaded files with a sha1-hash of the original filename and a randomnumber between 11111 and 99999 [why those numbers ?], ( done in sfValidatedFile::generateFilename ) is pretty ugly. No more seo-friendly filenames, filenames where you can actually have a clue about what's behind an url or how the creator supposed it to be named.

Nice and simple usability-boost for the filtering in the backend if you use it often and don't want to press the filter-button each time.
But it too can be annoying if you often filter based on date-fields and don't have a datepicker, because selecting a range is 6 changes and each time it get's submitted.

<script type="text/javascript">
  $(document).ready(function() {
    $('.sf_admin_filter select, .sf_admin_filter input[type="checkbox"]').attr('onchange', 'this.form.submit()');
  });
</script>

Symfony offers a fast and easy way for setting up admin backends including support for image uploads. You only need to change the fields widget and validator in the Form Class and symfony handles the rest:

  public function configure()
  {
    $this->widgetSchema['image'] = new sfWidgetFormInputFileEditable(array(
      'label' => 'Field Name',
      'file_src' => '/uploads/images/'.$this->getObject()->getImage(),
      'is_image' => true,
      'edit_mode' => !$this->isNew(),
      'template' => '%file% %input% %delete% %delete_label%'
    ));
    
    $this->validatorSchema['image'] = new sfValidatorFile(array(
      'required'   => false,
      'mime_types' => 'web_images',
      'path'       => sfConfig::get('sf_upload_dir').'/images',
    ));
    
    // delete checkbox
    $this->validatorSchema['image_delete'] = new sfValidatorPass();
  }

Combining that with the power of sfImageTransformExtraPlugin to create thumbnails of images based on profiles is really great:

When refactoring code or tests I like working until I break something. When my phpunit tests switch from green to red, I want to know it immediately without restarting the tests manually each time I change something, because that's annoying and a waste of time.
So after thinking about running the test-suite after each save in Netbeans, which I didn't find a way to do it and for unittests which run longer than some seconds, it wouldn't probably be such a good solution if after saving some changes the testsuite will take minutes to run. So I came up with another simple solution:

The new Truecrypt 7.0 release is almost 7 times faster compared to 6.0 on my i7-620M with AES-NI. It is some hundred mb/s faster now than dmcrypt (which runs my system-encryption on Debian Squeeze), but that is expected since truecrypt makes use of multiple cores AND aes-ni and dmcrypt only supports 1 thread per mounted device, so unless you create a RAID consisting of multiple dmcrypt-devices, you can only use 1 core.

Another nice thing, they ported the included benchmark-tool from windows to linux. In 6.3 there was no benchmarking when running under Linux, but now it is supported.

Truecrypt achieves between 1600 and 1700 mb/s. I ran the benchmark for 1mb, 5mb, 10mb, 50mb, 100mb and 1024mb, skipped 200mb and 500mb, because I was tooo lazy :)

Here are some images: