Emacs + Java

Появилась у меня в последнее время необходимость основательно познать Java. Очень долго не смотрел в его сторону, были у меня некоторые предубеждения. Я всегда думал, что plain C и Lisp это наше все. И этого достаточно. А сейчас работа повернулась стороной с Java лицом и соответственно захотел быстренько познать его особенности, а также настроить свой любимый редактор для удобной работы с этим популярным языком программирования.

Для каждого языка программирования в Emacs я стараюсь настроить следующие возможности:

• Подсветка синтаксиса (есть из коробки)
• Авто дополнения (желательно через auto-complete)
• Навигация по коду
• Работа с проектами (опционально, люблю работать в консоли вне Emacs)
• REPL (также опционально, но очень помогает во время обучения)

Из коробки в java-mode фактически работает только подсветка синтаксиса. Cedet идущий с Emacs'ом также позваляет настроить автодополнения и навигацию внутри классов. Но вот, например, системные вещи наотрез отказывается предлагать в качестве дополнений.

В общем я решил посмотреть, какие сейчас есть удобств для работы с Java в Emacs. При этом я наткнулся на следующие вещи:

• JDEE
• malabar-mode
• Eclime for Emacs
• Auto Java Complete
• CEDET Developer Version (Bazaar repo)

Немного впечатлений о каждом расширении. Все пробовал на MacBook Air, OS X, Emacs 24.3.1 из MacPorts.

JDEE

Старое и похоже переставшее развиваться расширение. Сразу не понравилось, что тянет с собой свою цветовую схему. Мелочи, но они всегда бросаются в глаза. Также JDEE каким-то образом умудряется нарушить работу whitespace-mode, который перестает подсвечивать вообще что-либо. Данную проблему решить не смог. Есть у меня подозрение, что это связано с перекрашиванием буфера, но глубока не капал за ненадобностью. Нечто похожее сейчас есть в markdown-mode. Ну и каких-то особых возможностей здесь не нашел. Все плюшки сделаны через Cedet, соответственно их можно получить и без JDEE.

Malabar-mode

Завязан на Maven, про который ранее слышал совсем чуть-чуть и отдаленно. Быстренько глянул, как работать с этим менеджером проектов. Создал тестовый проект, но производительность malabar-mode вообще не порадовала. Он как я понял использует Groovy console для формирования дополнений. И это похоже порой не быстрый процесс. В общем от этого варианта тоже отказался. Кроме того проект также загибается. Хотя в знакомстве с malabar-mode есть свой плюс: я узнал что такое Maven и как с ним работать.

Eclime

Вот это вообще монстр. Идея затащить в Emacs (изначально в Vim) функционал Eclipse через некий интерфейс тоже на деле оказывается не шибко производительна. В данном случае eclime запускает Eclipse на заднем плане и общается с ним, чтобы получить автодополнения и еще некоторый функционал (рефакторинг, навигация по коду и т.п.). Скорость отзывчивости данной системы еще меньше, чем у Malabar.

Auto Java Complete

Смысл данного расширения прост: сгенерировать теги необходимых Java библиотек и предоставить интерфейс для auto-complete. Я попробовал использовать готовые теги и это работает достаточно быстро и удобно. Но тут мы получаем только информацию системных библиотек и того что сами укажем ручками при генерации тегов. В принципе в связке со стандартным Cedet идущим с Emacs'ом должно всего этого хватить.

Cedet Dev

Самый удобный, как мне кажется, вариант это использовать последнюю версию Cedet из Bazaar репозитория. Тут сейчас Java хорошо поддерживается. Maven проекты кстати тоже отлично воспринимаются. По работе и настройке Cedet лучше обращаться к статье Alex Ott'а.

---

На данный момент я остановился на последнем варианте: Cedet Dev + auto-complete. Есть у кого еще предложения как улучшить жизнь в Emacs при работе с Java? Или все таки Cedet это наше все и смотреть в другие стороны лучше не стоит?

Как создать bridge на nfs root

Для поднятия сети на одной железке возникла необходимость создать bridge. Но загвоздка в том, что система должна при загрузке монтировать nfs в корень. Данное условие необходимо для возможности быстро изменить что-то в системе без необходимости лезть на флешку. Отладка идет полным ходом. Но основная проблема как раз в том, что при создании bridge сеть придется в любом случае оборвать. Nfs такого пережить не может и отваливается. Соответственно система дальше грузиться не может так как нету корневой файловой системы и сеть также сама вернуться не может.

Я уже думал искать какое-то альтернативное решение: как неожиданно мой коллега натолкнулся на небольшую заметку, в которой описано как обойти указанную проблему.

Сущность данного решения сводиться к тому, что надо все файлы, необходимые для настройки bridge, скопировать в раздел с tmpfs, который будет доступен после обрыва сети. Я, например, использовал /tmp. А потом запустить создание bridge из нового окружения. Данный метод работает на ура, нареканий не заметил.

Вот собственно решение с моими малюсенькими изменениями:

set -x
mount -o remount,exec /tmp
R=/tmp/root
IPADDR=192.168.0.159

mkdir -p "$R/proc"
cp -r /sbin /bin /lib "$R"
cat > "$R/script" <<EOF
mount -t proc none /proc
brctl addbr br0
brctl addif br0 eth0
ifconfig br0 "$IPADDR"
ifconfig eth0 0.0.0.0
umount /proc
EOF

chroot "$R" sh script
rm -r "$R/sbin" "$R/bin" "$R/lib"

В нутрь script в принципе можно вставить все, что вам будет необходимо.

Хорош ли метод? Мне по крайней мере понравился. Есть еще предложения, как возможно решить данный вопрос?

Хранение конфигурационных файлов (RCS & Git)

Когда-то давным давно, я впервые познакомился с системами контроля версий. Наверное это была CVS. Git'а тогда еще в планах думаю не было. Возникла у меня примерно в то далекое время логичная идея хранить все настройки в какой-нибудь подобной системе. Так совпало, что тогда же я активно изучал Emacs. И наткнулся тагда я на Version Control расширение. Именно оттуда я узнал о более древней системе: RCS. Как ни странно, именно в эту систему Emacs предлагает добавить файлы по умолчанию (C-x v v).

Так вот, с тех давних пор у меня все хранилось в RCS. Вообще говоря это достаточно удобно, если единственная задача: хранить историю изменений на одной машине. Все управление через Emacs. Я даже не особо знаю ключи команд ci и co.

Теперь же у меня фактически 4 компьютера, на которых я хотел бы иметь одинаковые, хотя бы, пользовательские настройки. Например, для bash или того же git. Для этого я задумал поместить все необходимые файлы из домашней директории в git репозиторий. Но положить в git всю или часть домашней директории похоже нехорошая идея. Однозначно будут глюки с git prompt. Если не добавить все файлы в .gitignore, то git prompt просто подвесит консоль: сканирование всей домашней директории не быстрое дело. Думаю это не единственная проблема.

Я решил воспользоваться следующей схемой. Нужные файлы скопировать в специальную папочку. В ней организовать git репозиторий. А в домашней директории создать ссылки на файлы из этой папки. Для автоматизации последней задачи я написал небольшой скриптик. Когда доработаю, выложу на github.

Еще одна проблема: специфичные настройки определенных машин. Например, PATH в Linux и OS X местами различаются (избыточности не хочется). В .gitconfig у меня даже различие есть. Для решения этого вопроса я создал для каждой машины, которой необходимы какие-то особенности, специальную ветку. Общие настройки хранятся на master ветке. Неудобство этой схемы связанно с тем, что надо постоянно сливать изменения с master'а в специфичные ветки. Может есть какое-то более простое и элегантное решение?

Ну а системные настройки (/etc/) я так и продолжаю хранить в RCS. Если будет задача настройки нескольких одинаковых машин, то можно будет подумать на тему синхронизации через git. Пока это не нужно. RCS хранит историю и этого достаточно. Насколько знаю portage в gentoo можно настроить для сохранения истории в RCS (см. /etc/dispatch-conf.conf). Но сам я этой возможностью не пользуюсь. Что-то там не состыковывается с моими привычками.

Gems и другие пакетные менеджеры

Только недавно столкнулся и попробовал использовать rubygems. Ранее все устанавливал через portage. Но частенько стали попадаться статьи, в которых пишут нечто вроде следующего:

gem install git-up
gem install bundle

Это добро у меня вызывало, некоторое недоумение (что еще за левые пакетные менеджеры???) и я бежал искать аналоги в portage. Частенько этого не находилось даже в различных overlay'ях. И вот в один из таких моментов, решив сэкономить время на поиск ebuild'ов, я все-таки выполнил указанную команду. И получил необходимое приложение в ~/.gem/ruby/1.9.1/bin.

Но тут пользователи gentoo столкнуться с некоторым затруднением. Этот дистрибутив не очень дружелюбен для ruby. То, что установится, не будет доступно в PATH. В других используемых мной системах аналогичной проблемы замечено не было. В OS X и Windows (Cygwin) PATH сам без дополнительных движений обновляется.

На bugs.gentoo.org нашел следующее универсальное решение. Создаем в папке /etc/profile файл следующего содержания:

if [[ -L "/usr/bin/ruby" ]]; then
    RUBY=$(readlink /usr/bin/ruby 2> /dev/null)

    case "${RUBY}" in
        *18) VERSION="1.8" ;;
        *19) VERSION="1.9.1" ;;
          *) VERSION="${RUBY##*/}" ;;
    esac

    export PATH="${HOME}/.gem/ruby/${VERSION}/bin:${PATH}"
fi

После этого все будет доступно как надо.

Похоже использовать gem намного удобнее, чем стандартный пакетный менеджер. Тем более на своей локальной машине с фактически одним пользователем (root не считается). Конечно можно добавлять себе постоянно новые overlay и писать новые ebuild. Но как показала моя практика это занимает существенно больше времени. Да и кроме того написание однотипных ebuild не особо интересное занятие. Генератора нету случаем? Не знаю как дело обстоит в других дистрибутивах, но думаю как-то также.

Еще в последнее время натолкнулся на pip для python и npm для node.js. Идея общественных хранилищ для программ, написанных на определенном языке как никак популярна сейчас. И это реально удобно.

Личный Firefox Sync

Для синхронизации браузерной информации я использую Firefox Sync. Но совсем недавно замучили проблемы синхронизации. Постоянно появлялась ошибка, что сервер не доступен, хотя на сайте mozilla не было сообщений о каких-то ошибках и неполадках в работе сервиса. Сейчас кстати есть:

The Firefox Sync service is undergoing some load issues, if you are experiencing problems please wait and try again soon. We are working on it presently.

Помучившись так недельку, я решил поднять личный Firefox Sync сервер на своем псевдо сервере. Быстренько нашел ebuild'ы для gentoo. И, вуа-ля, у меня рабочий сервер для синхронизации. Еще я написал init скрипты и выложил свой overlay на github. Если кому-то нужно — пользуйтесь на здоровье.

Плюсы которые обнаружил во время использования личного Firefox Sync сервера:

• Нет проблем с доступом, точнее их я могу решить сам. Более того, так как я единственный пользователь своего сервера, то нет проблем с загруженностью. А вот доступной поддержки для Firefox Sync не нашел. Признаюсь не сильно и искал.
• Фактически нет ограничения на размер хранимых данных. Стандартный 5-ти мегабайтный предел я умудрился превысить.

Git: Объединение merge коммитов

Возникла у меня на работе необходимость объединить два merge в один. Делал большое и несколько конфликтное слияние. А во время этого в Gerrit на мою ветку успели залить что-то новое, вызвавшее новые конфликты с моим merge. Соответственно необходимо было слить эти изменения тоже. На тот момент я видел следующие варианты:

• Самый простой способ: сделать еще один merge. В итоге получаем еще один дополнительный commit и разветвленную историю.
• Сделать полный merge заново. Повторять уже сделанное не хочется.

Я решил найти вариант, позволяющий в результате первого простого способа получить один коммит. Оказалось эта операция не совсем очевидна. Как всегда в последнее время, нашел решение на stackoverflow. Опишу весь процесс с начала до конца с историей тестового репозитория (git log --oneline --graph --decorate):

• Итак, мы сделали какой-то абстрактный merge master в feature ветку с исправлением всех конфликтов:

$ git checkout feature
$ git merge origin/master

*   b8c37f7 (HEAD, feature) c'
|\
| * 7020561 (origin/master) b
* | 2a55e67 (origin/feature) b'
|/
* b888f61 a

• Далее кто-то добавил что-то новое на feature ветку:

* 3820f07 (origin/feature) c'
| *   b8c37f7 (HEAD, feature) c'
| |\
|/ /
| * 7020561 (origin/master) b
* | 2a55e67 b'
|/
* b888f61 a

• Делаем дополнительный merge и видим не особо приятную историю:

$ git merge origin/feature

*   781dea7 (HEAD, feature) d'
|\
| * 3820f07 (origin/feature) c'
* |   b8c37f7 c'
|\ \
| |/
|/|
| * 7020561 (origin/master) b
* | 2a55e67 b'
|/
* b888f61 a

• А теперь собственно решение с выправлением истории. Делаем reset на коммит, с которого надо делать merge:

$ git reset --soft origin/feature

* 3820f07 (HEAD, origin/feature, feature) c'
* 2a55e67 b'
| * 7020561 (origin/master) b
|/
* b888f61 a

• Далее симулируем merge с origin/master и делаем commit:

$ git rev-parse origin/master > .git/MERGE_HEAD
$ git commit

*   3b01bf0 (HEAD, feature) d'
|\
| * 7020561 (origin/master) b
* | 3820f07 (origin/feature) c'
* | 2a55e67 b'
|/
* b888f61 a

Как видим в итоге получилась аккуратная история с необходимым полным слиянием веток. Теперь можно делать push. Данный способ можно использовать для объединения любого количества merge коммитов.

По идее надо запрещать людям добавлять новые изменения во время крупных слияний. Так будет возникать меньше затруднительных ситуаций.

Git + кириллические имена файлов на OS X

Не ожидал, что в мире современного ПО могут быть проблемы с Unicode. Мне казалось, что все неприятности с кодировками закончились с приходом Unicode'а. Давно по крайней мере с ними не встречался. Но, как оказалось, git несколько некорректно работает с русскими именами файлов на Mac'е.

Есть у меня репозиторий, в котором я храню все свои заметки. Половина из них была написана в muse-mode, остальное в Markdown. Соответственно имена файлов с текстом содержат заголовки, содержащие кириллицу. Мне так удобнее. Ранее с таким подходом ни разу проблем не встречал.

И вот проблема на Mac'е. Все русские буквы в выводе git status отображаются в восьмеричном виде. И более того все файлы содержащие в именах кириллицу помечаются как untracked. Пример:

$ izonov:text izonov$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   "linux/2013-05-24 - Git + \320\272\320\270\321\200\320\270\320\273\320\273\320\270\321\207\320\265\321\201\320\272\320\270\320\265 \320\270\320\274\320\265\320\275\320\260 \321\204\320\260\320\271\320\273\320\276\320\262 \320\275\320\260 OS X.md"
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   "linux/2013-05-24 - Git + \320\272\320\270\321\200\320\270\320\273\320\273\320\270\321\207\320\265\321\201\320\272\320\270\320\265 \320\270\320\274\320\265\320\275\320\260 \321\204\320\260\320\270\314\206\320\273\320\276\320\262 \320\275\320\260 OS X.md"
#   .....

Вторая проблема (untracked файлы) решается достаточно легко. Подсмотрено в вопросе на Stackoverflow:

git config --global core.precomposeunicode true

После этого видим следующее:

$ izonov:text izonov$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#   (use "git push" to publish your local commits)
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   "linux/2013-05-24 - Git + \320\272\320\270\321\200\320\270\320\273\320\273\320\270\321\207\320\265\321\201\320\272\320\270\320\265 \320\270\320\274\320\265\320\275\320\260 \321\204\320\260\320\271\320\273\320\276\320\262 \320\275\320\260 OS X.md"

Решения отображения русских букв в git status я не нашел. Кириллические символы в именах новых и измененных файлов все равно отображаются в восьмеричном виде. Как вариант можно использовать git add -i. Там все символы отображаются в привычном виде.

P.S. [2013-05-28]: Вчера Konstantin Khomoutov подсказал, как решить проблему отображения русских букв в git:

git config --global core.quotepath false

Evernote Web Clipper. Опять забыл пароль?

Довольно часто пользуюсь Evernote. Это действительно удобный инструмент для ведения заметок. Пользуюсь им с iPhone и через веб интерфейс с остальных систем (дом - Linux, работа - Windows). А теперь еще и оригинальным приложением для Mac'а пользоваться начал.

Все это к чему? Есть у этого замечательного сервиса казалось бы отличное дополнение для Firefox: Evernote Web Clipper. Но! После одного из последних обновлений он напрочь отказывается запоминать пароль и с жуткой периодичностью просит авторизоваться.

В Firefox на Mac'е подобные проблемы не наблюдаются. Логиниться часто не просит. Думаю это связано с тем что последнее обновление клиппера было установлено на чистый профиль.

Буду завтра на работе (до домашнего компа пока добраться не могу) пробовать установить Evernote Web clipper поверх нового профиля Firefox'а.

P.S. [2013-05-24] На работе поставил поверх чистого профиля клиппер. Он пароль вроде как перестал агрессивно спрашивать. Когда до стационарного компьютера доберусь, попробую найти файлы, которые надо почистить, чтобы профиль не менять.

Xbox One. Впечатления

Во время написания вчерашнего поста одним глазом смотрел презентацию Xbox One. Похоже уже давним являюсь поклонником Xbox'а. Давным давно купил Xbox 360 пополам с сестрой. Веселая была история! Чтобы уговорить сестру на подобную сделку, был куплен специальный розовый джойстик. До этого я долго не играл на PC, так как снес Windows и погрузился в мир Linux. Было в общем не до компьютерных развлечений. После приобретения приставки я вернулся в новый для меня мир игр. Сейчас же играю в основном в хоккейчик, но и то редко.

Вернемся к Xbox One. Девайс однозначно крутой. Начинка его будет покруче всех моих девайсов вместе взятых. И видимо надо будет брать, если будет желание порвать всех в новом хоккейчике. А он то однозначно будет.

Не понравились некоторые маркетинговые и дизайнерские фишки. Например само имя "Xbox Единственный" (не знаю как лучше перевести. "Xbox Один"?). У меня по крайней мере сразу складывается впечатление, что вот он венец игровых технологий и лучше точно не будет. Привередливый я. Напомнило iPad New и следующий за ним iPad 4. Напридумывают всяких хитрых имен для устройств, а потом мучаются. Кстати почему Xbox 360 я тоже не знаю. Не интересовался.

Сам вид нового устройства с первого раза больше напомнил страшно сказать Play Station. Черный, квадратно-прямоугольный. Где элегантность предыдущих Xbox'ов? Также ожидал, что все поместят в одну небольшую коробочку, а в итоге их две. Сенсор Kinect снова в отдельной коробке. В принципе понимаю почему так сделали (удобнее и легче Kinect устанавливать отдельно над или под телевизором). Но было бы думаю круто иметь одну компактную коробку вместо нескольких. Надеюсь они общаются без проводов. Пропустил этот момент.

В джойстике порадовало, что кнопку Xbox передвинули подальше вперед. На старых (ох, они уже старые) контроллерах периодически случайно эта кнопка нажимается. И это уж очень мешает игре.

Можно заметить, что мои претензии достаточно мизерны. Это все последствия моего дурного вкуса. Но мой совет всем: надо брать. Чего только стоит устроить танцевальную вечеринку (Dance Central). Сколько с друзьями не собирались все в полном восторге. Xbox однозначно лучший продукт Microsoft (как бы я недолюбливал эту компанию). Если игры и компьютерные развлечения, то только Xbox.

Macbook Air, блог и bash crash

Со вчерашнего дня решил писать по записи в день в данный блог, но умудрился уже проштрафиться. Просто напросто не успел. Этот план направлен на структуризацию своих мыслей. Хочу лучше понимать куда стремиться и чем лучше интересоваться, заниматься. Кроме того довольно часто начал сталкиваться с различными вопросами, решения которых не получается с первого раза найти в google (искать наверное разучился). Буду выносить все это дело в виде постов сюда. Постараюсь чтобы сюда попадали исключительно околотехнические темы. Остальное в Google+ или Twitter.

Итак начну с того, что любимая девушка подарила мне на день рождение MacBook Air. Поэтому с этого момента на данном блоге будут появляться посты посвященные и данному замечательному устройству, а также OS X (название блога видимо надо немного поменять). Все они будут помечены с помощью тега mac.

На Mac'е как раз и столкнулся с одной неприятной мелкой проблемой, которая несколько меня раздражает, но на данный момент я не знаю, как ее решить. Сразу же при получении этого девайся я начал устанавливать привычное мне консольное окружение. Для этого я использовал macports.

Настроил git completion и prompt, используя скрипты из git-core порта. Были установлены следующие версии портов:

• bash 4.2.42_0
• bash-completion 2.0_1
• git-core 1.8.2.3_0

И теперь, время от времени после выхода из свящего режима, bash падает вот с такой ошибкой:

-bash(23573,0x7fff75972180) malloc: *** error for object 0x7fb1cb40c530: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

При этом я не совсем уверен, что эта ошибка связана с bash-completion или git. Буду искать решение, но отказываться от completion и prompt совсем не хочется. Думаю попробовать bash из homebrew, ну или ручками собрать. Какие еще варианты? Куда копать на mac'е?

PS. Вот и ушло у меня пару часов на написание казалось бы небольшого текста.

P.S. [2013-05-25] bash все равно продолжает падать даже с выключенными completions и git-prompt. Происходит это стабильно раз в день.

Infinality патчи на стабильной ветке

Как-то я пропустил тот факт, что похоже уже давно infinality патчи находятся на стабильной ветке в gentoo portage. До этого ставил их из lcd-filtering. Теперь все намного проще. Добавляем USE-флаг infinality в make.conf и пересобираем freetype:

emerge -1q freetype
eselect fontconfig enable 52-infinality.conf
eselect infinality set infinality
eselect lcdfilter set infinality

Как видим теперь необходимо несколько раз дополнительно запустить eselect. При этом вариантов для выбора eselect infinality и eselect lcdfilter предоставляют многовато. Я с ними не экспериментировал. Если кто пробовал, поделитесь впечатлениями.

Использование Gitolite вместе с Redmine

Появилась необходимость добавить git репозиторий в Redmine проект на домашнем сервере. Для управления git репозиториями использую Gitolite. Как оказалось по-умолчанию Gitolite запрещает доступ всем кроме пользователя, которым он обслуживается. В моем случае доступ есть только у пользователя git. Redmine же запускает пользователь redmine. В общем главная загвоздка — найти umask опцию в настройках Gitolite.

Решение со Stackoverflow:

• Добавляем в Redmine путь к необходимому репозиторию. Например: /home/git/repositories/repo.git.

• Добавить пользователя, который запускает веб-сервер с Redmine в git-группу:

    usermod -a -G git redmine
  

• В файле .gitolite.rc (находится в домашней директории git) поменять значение UMASK с 0077 на 0027. Теперь новые файлы Gitolite будет создавать с правами на чтение для группы git.

• Также необходимо поменять права доступа для всех существующих репозиториев. В директории с репозиториями запускаем следующее:

    chmod -R g+rX
  

Есть еще варианты решения этого вопроса?

Svn to Git

Краткая инструкция миграции с svn на git.

Руководство к действию

• Найти всех авторов с помощью скрипта

  #!/usr/bin/env bash
  authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq)
  for author in ${authors}; do
      echo "${author} = NAME <EMAIL>";
  done
  

  Все записи NAME и EMAIL вручную заменяем на необходимые значения.

• Склонировать svn репозиторий

  git svn clone [-s] --no-metadata --username=USER --authors-file=SVN-AUTHORS SVN_URL
  

  Пара слов про опции:

  • -s — необходима, если используются стандартные svn папки (trunk, tags, branches).
  • --no-metadata — удаление записей git-svn-id из логов.
  • --username — тут все понятно.
  • --author-file — список авторов в svn репозитории (см. пункт выше).

• Импорт ignore файлов

  На каждой ветке необходимо сделать следующее:

  git checkout BRANCH
  git svn create-ignore
  git commit -a -m "Import svn:ignore."
  

Полезные ссылки

Весь этот небольшой материал основан на следующих статьях:

• Перенос SVN-репозитария в git
• Habr: Переезд проекта с SVN на Git
• Habr: how to: Как и зачем работать с svn через git

Blogger пост из Emacs? Markdown + Googlecl script

Побаловался с googlecl. Умудрился случайно наделать множество постов, состоящих всего лишь из одного слова в своем читальном блоге. Сейчас вроде бы все исправил. Постараюсь подобное предотвращать в будущем. Но главное — проверил, что googlecl работает. Далее хочу обсудить варианты публикации сообщений из Emacs.

Ранее для написания заметок я использовал muse-mode. Каждая muse-заметка экспортировалась в html. А далее я ручками копировал в форму Блоггера нужный контент. Долго я пользовался именно этой схемой. Muse в какой-то момент перестал удовлетворять моим требованиям. Были у него некоторые проблемы со вложенными списками и вставками кода. А всякие списки я ой как люблю. Это наверное последствия долгого использования org-mode. Ну а потом я вообще перестал что-либо публиковать в сети.

Также когда-то я пробовал наладить google интерфейс, который шел в поставке с emacsspeak. Но безуспешно. Интересно в каком состоянии он сейчас? Давно не слышал.

Теперь я собираюсь изобрести новый велосипед. В его основе Markdown и Googlecl. Собственно смысл в том, чтобы написать мини скрипт на bash, который переведет md-файл в html (python-markdown). При этом он должен вырезать избыточные поля. Например, заголовок, который в блоггере в отдельное поле вводится. Далее отправить это добро в googlecl, который успешно опубликует новую заметку с правильным заголовком и тегами в нужном месте. То есть из Emacs надо будет дернуть этот скриптик и собственно все.

Как вариант можно написать полностью тоже самое на elisp, но хочется простой возможности публиковать файлы из консоли. Также я пока не совсем понимаю, как настроить раскраску кода при конвертировании md в html, но думаю с этим больших проблем не должно быть.

Как вам такая схема? Не слишком ли я заворачиваю? Сейчас буду реализовывать это добро.