Даже рад, если на github будет разработка, меньше потрачусь. Но вот вопрос, можно ли там прикручивать конвертеры?

Да и вообще, может стоит размещать хранилища на github?

Это хорошо, но для git проще как оказалось сделать конвертер для сравнения.

Для хранения бинарных файлов, например, электронной библиотеки, Git подходит лучше. По сравнению с Mercurial он не ориентирован на расчет дельты файлов, что для бинарного содержимого не очень эффективно. Сами файлы меняются редко, а основные операции с ними — это перемещение и добавление. По моим собственным наблюдениям папка хранилища Git с историей моей библиотеки сопоставима по размерам с рабочей копией с окрестностью примерно 10%.

Pack-файлы

Если бы Git действительно хранил все объекты целиком (хоть и сжатые), папка .git представляла бы из себя огромный набор файлов, причем их бы было гораздо больше, чем в рабочей копии. Тем не менее этого не происходит, а появляются загадочные pack-файлы, в которые упакованы объекты. Как ни странно, но в интернете мало информации о том, как Git хранит данные в этих файлах, поэтому приведем отрывок из электронного письма Линуса Торвальдса, в котором дается некоторое пояснение насчёт этих загадочных файлов (источник: gcc.gnu.org/ml/gcc/2007-12/msg00165.html):
Скрытый текст

Если кратко, то в pack-файлах объекты группируются по схожести (например, тип и размер), после чего они сохраняются в виде «цепочек». Первый элемент цепочки представляет из себя самую новую версию объекта, а следующий за ним являются диффом к предыдущему. Самые новые версии объекта считаются наиболее запрашиваемыми, поэтому они хранятся выше в цепочке.

Таким образом, Git всё же хранит диффы, но только на уровне непосредственного хранения данных. С точки зрения любого API уровнем выше, Git оперирует объектами целиком, что позволяет реализовывать различные стратегии слияния и легко разрешать конфликты.