We have an inconsistent mix of multi-word file names that use dash vs. underscore to separate those words. $ git ls-files '**/*_*' | wc 2497 2497 146485 $ git ls-files '**/*-*' | wc 8147 8147 444426 Some of those are overlaps (meaning we can't make up our minds), such as: docs/api_extension/0001-add-to-xml.patch However, my personal preference is to use dash everywhere (or at least on all the .[ch] files), for at least several reasons: 1. dash is easier to type (at least on US keyboards), as it does not require the shift key [I find it easier to edit files in tools/ than in src/qemu/ for example, because I don't have to worry about shift] 2. include/ uses only dash, not underscore; if our public interface favors that spelling, our internal files should too 3. underscore is easier to miss visually when other markup like underline is being applied (for example, when viewing the git repository online and hovering over a filename). Granted, you can still often tell that an underscore is present vs. a space (or in general, realize that we avoid spaces in file names in our git tree, so it must be an underscore); but I still find dash much easier to pick out. Since git rename detection does a good job at tracking history by content over file renames, a mass rename wouldn't even be that invasive to git archaeology or patch backporting. If you're worried about finger memory typing the wrong form, but you use bash, it's possible to configure bash to treat '-' and '_' interchangeably during TAB-completion (similar to case insensitive tab completion), which reduces some of the pain, but it doesn't solve everything. So, would anyone like a beginner's project of consistently renaming files, and/or would anyone object if I submitted some patches along those lines? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org