Git 2.0.0



    Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

    Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

    Поведение Git 1.*:
    git config --global push.default matching
    

    Новое поведение по умолчанию в Git 2.0:
    git config --global push.default simple
    

    Другие изменения:
    • команды git add --update и git add --all если не указан конкретный путь в параметре будут применены ко всему дереву, даже если команда была запущена внутри подкаталога
    • git add и git add --all сейчас одно и то же
      удален параметр core.statinfo, который был недокументированным синонимом core.checkstat
      git pull теперь может быть настроен так, чтобы работал только в режиме fast-forward (опция pull.ff)
      git rebase интерпретирует "-" как "@{-1}" (возврат к предыдущей активной ветке)
      пробельные символы в конце строк файла .gitignore будут проигнорированы и вы получите warning
      команды, создающие коммиты (pull, rebase и т.д.) научились понимать параметр --gpg-sign
      git commit теперь может всегда подписывать новые коммиты если вы установите commit.gpgsign значение true
      git reset выучил опцию -N, которая идет рядом с --mixed (подробнее о git reset в моей предыдущей статье). Если указан -N удаленные пути будут помечены как intent-to-add


      Это основные изменения на мой взгляд, вот полный whats-new список.

      You can only really use Git if you understand how Git works.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 20

      +13
      Хотелось бы отметить, что смена главной версии обусловлена не какими-то крупными изменениями (которых нет), а тем, что были внесены несовместимые изменения. Так что по по semver-у это новый major-релиз.
        0
        Хотелось бы также вспомнить, как совсем не по семверу после mercurial v2.9.x был выпущен v3.0.0
        –2
        Хочу задать вопрос, который давно мучает.
        Ведётся ли какая-нибудь работа над серверной частью git? Не хватает, например, возможности посмотреть лог без выкачивания всего дерева коммитов на локальную машину, и прочих элементарных вещей. Конечно, это привычки, оставшиеся от svn, но почему бы нет?
          +42
          Потому что git по определению — децентрализованная система :)
            +9
            Ответ не совсем корректный. Децентрализация, теоретически, сама по себе не противоречит возможности выкачивать часть связанных объектов.

            Правильный ответ: потому что объекты git иммутабельны. Не имея части связанных коммитов, локальная копия попросту не сможет выстроиться в корректный лог. С другой стороны, для построения лога не требуется непременно иметь деревья файлов локально. Вот тут можно было бы кое-что улучшить в гите, не нарушая при этом ни иммутабельность, ни децентрализацию.
              –2
              Вопрос заключался в разработке серверной части. Сторонних разработок существует несколько, но это не задача разработчиков git'а.
                0
                Вообще-то, gitweb есть в коробке. В принципе его хватает для просмотра быстрого коммитов через веб. Локально можно запустить с помощью git instaweb.
                И, кстати, практически все серверные решения основаны на использовании протокола ssh. Не обязательно для пары тройки личных репозиториев ставить gitorius, gitlab и etc. В свое время довольно долго сидел на связки gitosys + gitweb, пока не понял, что не хватает.
          • UFO just landed and posted this here
              0
              У себя поставил cgit. Можно посмотреть историю коммитов, ветвление и тд…
                +1
                Очень советую посмотреть в сторону gitlab.
              +16
              > Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.
              Это, видимо, какая-то стандартная фраза новости про новую версию, но к Git 2.0 она не совсем применима. Как сказали выше habrahabr.ru/post/225251/#comment_7658189 ничего там отличающегося от обычного major-релиза нет, кроме пары breaking changes.
                0
                Под винду предлагает все равно старую версию загружать. Могли бы подождать еще день, чтобы успеть под все платформы пакеты собрать.
                  +1
                  С Windows разговор отдельный. Насколько я понимаю, портированием на нее занимается другая команда, и отставание у них довольно заметное — порты версий 1.9.3 и 1.9.4 так и не появились, хотя может они как раз ждали мажорного релиза.
                  +2
                  Больше всего убивает что гит после коммита никак не проверяет что же там записалось в objects и не умер ли репозиторий из-за этого (error: sha1 mismatch). Подобное периодически происходит в одном локальном репозитории под win (другой софт проблем ни с памятью ни с диском не испытывал и не испытывает), ужасно бесит. Ну и отдельно радует «официальный» способ починки — угадать содержимое древнего файла дающее требуемую sha1…

                  Может можно как нибудь научить его этой проверке? (возможно, через тот же git fsck)
                    0
                    может, делать checkout на предыдущий коммит и потом сразу на последний?
                      +1
                      С одной стороны — верно, а с другой подозрительность ко внешним носителям можно довести до полной паранои. Проверять, что в память записалось то значение, которое собирались записать, например.

                      Вопрос в том задача ли это для прикладного софта?
                        +2
                        1) Кто тогда должен следить за состоянием репозитория?
                        2) Почему можно продолжать коммитить в, по сути, мертвый репозиторий?
                          0
                          Если я правильно понимаю вашу проблему, то происходит следующее:

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

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

                      Only users with full accounts can post comments. Log in, please.