Во- первых, оказалось, что explorer.exe в Windows умеет выделять файл, буквы имени которого вы печатаете. Да-да, просто открываете Проводник и, не кликая ни на какие другие элементы интерфейса, начинаете печатать. Проверял - работает в Windows XP и в Windows 7.
Второе открытие несколько посерьезней...
С давних пор я храню свои конфигурационные файлы в системе контроля версий: https://github.com/h0rr0rrdrag0n/dotfiles. Преимущества: история изменения файлов, с возможностью откатиться к любому из стабильных состояний, что были в прошлом. Также, для меня бывает удобно посмотреть, что же там такое поменялось в конфигах...
И сегодня, мне в голову пришла идея использовать один из механизмов системы контроля версий, а именно - ветки (branches), для того чтобы получить несколько версий одного и того же конфигурационного файла для разных платформ. Например: в Linux'е я использую расширение Emacs'а AuCTeX, а в Windows же оно мне не нужно и, соответственно, я хочу иметь две разных версии ~/.emacs - со включенным плагином и с отключенным.
Решение здесь простое как три копейки - создается отдельная ветка конфигов для линукса, где плагин включен и отдельная ветка конфигов для винды, где все отключено и удалены конфиги Xmonad'а и прочих, отсутствующих в операционной системе от Microsoft, вещей.
Выглядит как-то так:
Используется это так:
- Сначала клонируется репозиторий, если это еще не было сделано, через git clone repo-url. В итоге, мы получаем что-то такое, как на скриншоте выше;
- Затем, необходимая ветка (в нашем случае windows-cygwin) пуллится в локальный репозиторий через git checkout windows-cygwin;
- Теперь можно производить необходимые изменения в конфигах, по завершении которых нужно закоммитить изменения в ветку и запушить ее на сервер. Так, например, я удалил конфиги Xmonad'а в ветке для Windows:
Еще рассмотрим одну, более интересную штуку. Как видно, у нас осталась ветка master, в который мы будем работать с файлами, общими для всех платформ. Было бы неплохо поменять что-то в ветке master, а потом сразу сделать соответствующие обновления во всех остальных ветках, одним движением руки.
Вначале, рассмотрим как сделать что-то подобное ручками. Я удалю из ветки master каталог ~/.fluxbox, а затем распространю это изменение на все остальные ветки:
На скриншоте, я сначала удаляю "как обычно" ненужный каталог из ветки master, ну а потом, через git cherry-pick распространяю это изменение на ветки windows-cygwin и linux.
Конечно, делать однообразные действия ручками не комильфо, поэтому я написан небольшой скрипт, который автоматизирует работу по распространению изменений.
Скрипт прост и незатейлив -- в цикле перебирает все ветки и сливает в них через cherry-pick коммит с тегом, который был передан скрипту в качестве первого параметра. Подразумевается, что в момент запуска скрипта мы находимся в ветке master и команды git commit и git tag уже были выполнены. Потом, может быть, под настроение, допилю этот скрипт, добавив соответствующие проверки...
Haters gonna hate^W^W^WПредвижу, что будут недоуменные вопросы: "зачем тут бледная шпаргалка по принципам работы в Git'е?". Поэтому сразу отмечу, что основное в данном посте не гит, а, возможно не самая свежая, идея хранить конфигурацию рабочей среды в VCS, распределяя конфиги для различных платформ по веткам...
P.S. А еще можно простым git checkout branchname быстро переключаться между различными версиями конфигов на лету. А если еще прицепить к этому симлинки, чтобы конфиги были в каталоге в репозиторием, а там, где они используются, был бы симлинк...