Monday, June 22, 2009

Quick post on working with large changes across your codebase

Stuff I wrote up for work. Ignore the p4 part, assuming you use a real version control system, *cough* git.

Strategies for making changes that affect a large number of files


  • recursive editing (C-r, C-M-c)
  • find-grep-dired
  • ibuffer (Used to save large number of buffers at once)
  • dired-do-query-replace-regexp (find-replace across marked files in dired buffer)


  • grep -rIl 'pattern' * > files_to_op_on (that's a capital i and a lowercase L)
    • grep option -r: recurse
    • grep option -I: (capital i) exclude binary files
    • grep option -l: (lowercase L) Show only filenames with matching content, no other output.
    • grep option -h: don't include filename in the match line.
  • cat files_to_op_on | xargs sed -i backup_extension 's/old/new/g' #Note that bsd sed required a backup extension with the -i argument.
  • cat files_to_op_on | xargs p4 edit

Watch out for symlinks! If you get them in your changelist, p4 won't accept submit, in which case you'll need to delete them via p4 change.

p4 submit > /dev/null
works well to just get the errors.

The general pattern of:

grep -rI 'something' * | sort -u
can show you the variations you'll need to fix. If you want to get rid of leading whitespace in your results, try piping through:
 sed -E -e 's/^[[:space:]]+//'