Git 2.0.0

[@StreetStrider]

Хотелось бы отметить, что смена главной версии обусловлена не какими-то крупными изменениями (которых нет), а тем, что были внесены несовместимые изменения. Так что по по semver-у это новый major-релиз.

[@zerkms]

Хотелось бы также вспомнить, как совсем не по семверу после mercurial v2.9.x был выпущен v3.0.0

[@Biga]

Хочу задать вопрос, который давно мучает.
Ведётся ли какая-нибудь работа над серверной частью git? Не хватает, например, возможности посмотреть лог без выкачивания всего дерева коммитов на локальную машину, и прочих элементарных вещей. Конечно, это привычки, оставшиеся от svn, но почему бы нет?

[@xobb1t]

Потому что git по определению — децентрализованная система :)

[@eliah_lakhin]

Ответ не совсем корректный. Децентрализация, теоретически, сама по себе не противоречит возможности выкачивать часть связанных объектов.

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

[@xobb1t]

Вопрос заключался в разработке серверной части. Сторонних разработок существует несколько, но это не задача разработчиков git'а.

[@AgentSIB]

Вообще-то, gitweb есть в коробке. В принципе его хватает для просмотра быстрого коммитов через веб. Локально можно запустить с помощью git instaweb.
И, кстати, практически все серверные решения основаны на использовании протокола ssh. Не обязательно для пары тройки личных репозиториев ставить gitorius, gitlab и etc. В свое время довольно долго сидел на связки gitosys + gitweb, пока не понял, что не хватает.

[@skul]

У себя поставил cgit. Можно посмотреть историю коммитов, ветвление и тд…

[@scipe]

Очень советую посмотреть в сторону gitlab.

[@outcoldman]

> Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.
Это, видимо, какая-то стандартная фраза новости про новую версию, но к Git 2.0 она не совсем применима. Как сказали выше habrahabr.ru/post/225251/#comment_7658189 ничего там отличающегося от обычного major-релиза нет, кроме пары breaking changes.

[@Witold]

С Windows разговор отдельный. Насколько я понимаю, портированием на нее занимается другая команда, и отставание у них довольно заметное — порты версий 1.9.3 и 1.9.4 так и не появились, хотя может они как раз ждали мажорного релиза.

[@LastDragon]

Больше всего убивает что гит после коммита никак не проверяет что же там записалось в objects и не умер ли репозиторий из-за этого (error: sha1 mismatch). Подобное периодически происходит в одном локальном репозитории под win (другой софт проблем ни с памятью ни с диском не испытывал и не испытывает), ужасно бесит. Ну и отдельно радует «официальный» способ починки — угадать содержимое древнего файла дающее требуемую sha1…

Может можно как нибудь научить его этой проверке? (возможно, через тот же git fsck)

[@ivanzoid]

может, делать checkout на предыдущий коммит и потом сразу на последний?

[@boblenin]

С одной стороны — верно, а с другой подозрительность ко внешним носителям можно довести до полной паранои. Проверять, что в память записалось то значение, которое собирались записать, например.

Вопрос в том задача ли это для прикладного софта?

[@LastDragon]

1) Кто тогда должен следить за состоянием репозитория?
2) Почему можно продолжать коммитить в, по сути, мертвый репозиторий?

[@boblenin]

Если я правильно понимаю вашу проблему, то происходит следующее:

1) git создает объект и считает sha1
2) во время записи объекта или хэша — происходит ошибка
3) записаные данные не соответствуют тому, что было на входе

по мне это скорее всего проблема с файловой системой, хотя это как диагноз по фотографии… на других локальных репозиториях этого же не происходит, так?

[@LastDragon]

Угу (в последний раз не записался кусок текстового файла — начало есть, а конца нет). Вызвано это скорее всего тем, что параллельно открыт eclipse c jgit-ом, а коммичу из tortoise git. На других репозиториях не наблюдается, но там и активность меньше.

[@clockworkbird]

Была похожая ситуация на одном боевом проекте.
Решилась установкой одинаковых версий на сервере и у всех участников. После этого сбоев и падений репозиториев не было.