Comments 20
Хотелось бы отметить, что смена главной версии обусловлена не какими-то крупными изменениями (которых нет), а тем, что были внесены несовместимые изменения. Так что по по semver-у это новый major-релиз.
Хочу задать вопрос, который давно мучает.
Ведётся ли какая-нибудь работа над серверной частью git? Не хватает, например, возможности посмотреть лог без выкачивания всего дерева коммитов на локальную машину, и прочих элементарных вещей. Конечно, это привычки, оставшиеся от svn, но почему бы нет?
Ведётся ли какая-нибудь работа над серверной частью git? Не хватает, например, возможности посмотреть лог без выкачивания всего дерева коммитов на локальную машину, и прочих элементарных вещей. Конечно, это привычки, оставшиеся от svn, но почему бы нет?
Потому что git по определению — децентрализованная система :)
Ответ не совсем корректный. Децентрализация, теоретически, сама по себе не противоречит возможности выкачивать часть связанных объектов.
Правильный ответ: потому что объекты git иммутабельны. Не имея части связанных коммитов, локальная копия попросту не сможет выстроиться в корректный лог. С другой стороны, для построения лога не требуется непременно иметь деревья файлов локально. Вот тут можно было бы кое-что улучшить в гите, не нарушая при этом ни иммутабельность, ни децентрализацию.
Правильный ответ: потому что объекты git иммутабельны. Не имея части связанных коммитов, локальная копия попросту не сможет выстроиться в корректный лог. С другой стороны, для построения лога не требуется непременно иметь деревья файлов локально. Вот тут можно было бы кое-что улучшить в гите, не нарушая при этом ни иммутабельность, ни децентрализацию.
Вопрос заключался в разработке серверной части. Сторонних разработок существует несколько, но это не задача разработчиков git'а.
Вообще-то, gitweb есть в коробке. В принципе его хватает для просмотра быстрого коммитов через веб. Локально можно запустить с помощью git instaweb.
И, кстати, практически все серверные решения основаны на использовании протокола ssh. Не обязательно для пары тройки личных репозиториев ставить gitorius, gitlab и etc. В свое время довольно долго сидел на связки gitosys + gitweb, пока не понял, что не хватает.
И, кстати, практически все серверные решения основаны на использовании протокола ssh. Не обязательно для пары тройки личных репозиториев ставить gitorius, gitlab и etc. В свое время довольно долго сидел на связки gitosys + gitweb, пока не понял, что не хватает.
UFO just landed and posted this here
У себя поставил cgit. Можно посмотреть историю коммитов, ветвление и тд…
> Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.
Это, видимо, какая-то стандартная фраза новости про новую версию, но к Git 2.0 она не совсем применима. Как сказали выше habrahabr.ru/post/225251/#comment_7658189 ничего там отличающегося от обычного major-релиза нет, кроме пары breaking changes.
Это, видимо, какая-то стандартная фраза новости про новую версию, но к Git 2.0 она не совсем применима. Как сказали выше habrahabr.ru/post/225251/#comment_7658189 ничего там отличающегося от обычного major-релиза нет, кроме пары breaking changes.
UFO just landed and posted this here
Больше всего убивает что гит после коммита никак не проверяет что же там записалось в objects и не умер ли репозиторий из-за этого (error: sha1 mismatch). Подобное периодически происходит в одном локальном репозитории под win (другой софт проблем ни с памятью ни с диском не испытывал и не испытывает), ужасно бесит. Ну и отдельно радует «официальный» способ починки — угадать содержимое древнего файла дающее требуемую sha1…
Может можно как нибудь научить его этой проверке? (возможно, через тот же git fsck)
Может можно как нибудь научить его этой проверке? (возможно, через тот же git fsck)
может, делать checkout на предыдущий коммит и потом сразу на последний?
С одной стороны — верно, а с другой подозрительность ко внешним носителям можно довести до полной паранои. Проверять, что в память записалось то значение, которое собирались записать, например.
Вопрос в том задача ли это для прикладного софта?
Вопрос в том задача ли это для прикладного софта?
1) Кто тогда должен следить за состоянием репозитория?
2) Почему можно продолжать коммитить в, по сути, мертвый репозиторий?
2) Почему можно продолжать коммитить в, по сути, мертвый репозиторий?
Если я правильно понимаю вашу проблему, то происходит следующее:
1) git создает объект и считает sha1
2) во время записи объекта или хэша — происходит ошибка
3) записаные данные не соответствуют тому, что было на входе
по мне это скорее всего проблема с файловой системой, хотя это как диагноз по фотографии… на других локальных репозиториях этого же не происходит, так?
1) git создает объект и считает sha1
2) во время записи объекта или хэша — происходит ошибка
3) записаные данные не соответствуют тому, что было на входе
по мне это скорее всего проблема с файловой системой, хотя это как диагноз по фотографии… на других локальных репозиториях этого же не происходит, так?
Была похожая ситуация на одном боевом проекте.
Решилась установкой одинаковых версий на сервере и у всех участников. После этого сбоев и падений репозиториев не было.
Решилась установкой одинаковых версий на сервере и у всех участников. После этого сбоев и падений репозиториев не было.
Sign up to leave a comment.
Git 2.0.0