LINUX.ORG.RU

Git 2.7.0

 


0

3

Команда разработчиков Git рада сообщить о релизе Git 2.7.0.

Этот выпуск содержит более 800 коммитов от 81 автора, 26 из которых не так давно присоединились к проекту.

git bisect теперь не только для регрессий

Несмотря на то, что git bisect наиболее часто используется для поиска регрессий, такой подход может быть применён при поиске любых других изменений. Какие бы изменения вы не искали, вы отмечаете хорошими ревизии до изменений и плохими после. Это может путать, особенно, если вы хотите найти коммит, исправляющий ошибку. Чтобы решить эту проблему, добавлена возможность вместо good и bad использовать свои собственные термины. Без дополнительных настроек можно использовать более нейтральные термины old и new:

$ git bisect start
$ git bisect old v4.2
$ git bisect new master

Указать свои собственные термины можно следующим образом:

$ git bisect start --term-old yucky --term-new yummy
$ git bisect yucky v4.2
$ git bisect yummy master

Новый параметр конфигурации для --recurse-submodules

Если вы используете субмодули, то вероятно совершали ошибку при отправке изменений в главный модуль без первоначальной отправки соответствующих изменений в субмодули. Надо было указывать опцию --recurse-submodules, например:

$ git push --recurse-submodules=on-demand origin

Теперь вы можете задать такое поведение по умолчанию с помощью нового параметра конфигурации:

$ git config push.recurseSubmodules on-demand

Если вы предпочитаете, чтобы Git предупреждал о потенциальных проблемах, используйте:

$ git config push.recurseSubmodules check

Дальнейшее совершенствование worktree

Помните команду git worktree, которая была введена в Git 2.5.0? Она позволяет создавать множественные рабочие копии, которые связаны с одним локальным репозиторием Git.

В Git 2.7.0, git worktree продолжает улучшаться:

  • Новая команда git worktree list позволяет получить список рабочих копий, связанных с текущим репозиторием.
  • git bisect теперь может запускаться в любом worktree, или даже в двух одновременно.
  • Вы теперь можете клонировать из связанного worktree.
  • Улучшена поддержка субмодулей.

Поддержка git LFS для git p4

git p4 является мостом между Git и Perforce, который позволяет получать коммиты из Perforce в Git, отправлять коммиты из Git на сервер Perforce и т. д. (Существуют похожие инструменты для работы с Subversion, Mercurial, Bazaar, TFS, и др.) git p4 теперь может хранить большие файлы в Git LFS («Git Large File Storage»), что позволяет избежать раздувания репозитория на диске. Обратите внимание, что эта функция пока не поддерживает git p4 submit.

Более согласованные команды для получения списка ссылок

В Git есть три основных способа получения списка ссылок: git branch для веток; git tag для меток; и git for-each-ref для ссылок любого типа. Но эти команды, несмотря на их перекрывающуюся функциональность, имели разные возможности и опции.

Теперь, благодаря работе студента Google Summer of Code, Karthik Nayak, эти команды имеют более согласованный интерфейс. Все три команды поддерживают следующие опции:

  • --points-at <object>: получить список ссылок которые указывают на заданный объект;
  • --merged [<commit>]: получить список ссылок, которые были объединены с коммитом (HEAD по умолчанию);
  • --no-merged [<commit>]: получить список ссылок, которые не были объединены с коммитом (HEAD по умолчанию);
  • --contains [<commit>]: получить список ссылок которые содержат указанный коммит (HEAD по умолчанию).

Они также получили новое форматирование и параметры сортировки.

Другие изменения

  • git stash show теперь поддерживает два параметра конфигурации: stash.showPatch и stash.showDiff, которые задают формат вывода по умолчанию.
  • git blame теперь корректно работает с опцией --first-parent, а также, когда --reverse и --first-parent используются вместе.
  • Улучшен внешний вид gitk на high-DPI мониторах.
  • Исправления безопасности [1] [2].

>>> Официальный анонс

>>> Примечания к выпуску

>>> Подробности

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 8)

Ответ на: комментарий от hobbit

Рутинная бессмысленная работа, которую можно было потратить на внедрение новых фич.

Переписал же, не развалился от этого? Такую же работу могли подкинуть и в оригинальном ПО к которому делаешь морду («бессмысленную» т.е.). Гуй делают не просто чтобы он был для галочки, а чтобы было удобно пользоваться приложением и ради этого приходится обновлять его под тулкиты.

Некоторые вообще одновременно поддерживают сразу несколько тулкитов (transmission, например, есть для gtk+3 qt4 qt5 и osx) и не ноют же особо потому что задача у людей сделать удобное ПО, а не нахерачить гогно для галочки. Если считаешь это бессмысленной работой, то и нечего браться за интерфейсы.

mashina ★★★★★
()
Ответ на: комментарий от anonymous

И что же есть cуть этого самого ДинамикВью?

Условно говоря, ты можешь смонтировать из разных частей репозитория что-то типа файловой системы аля NFS или виндового «сетевого диска». При этом, есть довольно гибкие средства для формирования того, что ты на этом «диске» увидишь.

Просто ви так об энтом пишете, словно бы до git'a каждый пользовался энтой рекламируемой описываемой вами проприетарщиной.

Clearcase производит неизгладимое впечатление на всех, кто с этим чудом сталкивался.

gns ★★★★★
()
Ответ на: комментарий от anonymous

Прошло 5 лет, и им надо переписывать всё под qt4 или gtk3. И тестировать. Пройдёт ещё 5 лет, и придётся... правильно, снова переписывать.

А никто не обещал, что будет легко. Такова жизнь. Не хочешь (или не умеешь) делать - не делай, только не надо придумывать глупых отмазок.

anonymous
()
Ответ на: комментарий от gns

Atlassian, github, gitlab, да все кому не лень предлагают решения.

Git сам по себе это «stupid content tracker». К нему всё остальное снаружи дописывается легко. Тот-же gitolite, если посмотришь, как он устроен: git даёт тебе хуки, а ты уж привязываешь к ним, что хочешь.

rupert ★★★★★
()
Ответ на: комментарий от gns

Условно говоря, ты можешь смонтировать из разных частей репозитория что-то типа файловой системы аля NFS или виндового «сетевого диска». При этом, есть довольно гибкие средства для формирования того, что ты на этом «диске» увидишь.

Симлинки с fuse изобрели? Совершенно бесполезная фича для SCM, но для типичной корпоративной файловой пойки, засунутой в VCS, может быть и полезна мастдайным пользователям.

Clearcase производит неизгладимое впечатление на всех, кто с этим чудом сталкивался.

Эхо по треду от неизгладимых впечатлений выглядит каким-то неадекватным, скорее оно похоже на психологическую травму.

mashina ★★★★★
()
Ответ на: комментарий от gns

Clearcase производит неизгладимое впечатление на всех, кто с этим чудом сталкивался.

С clearcase-ом сношаться радость ещё та. Помню, как я стчетно пытался в их документации найти ответы на простейшие вопросы и сооружал трёх метровые команды, которые в других VCS делаются тривиально. Безо всякого гуя! Гуй, если он даже и был, всё равно бы не взлетел на сане или powerpc через ssh.

До сих пор где-то валяется ссылка на список clearcase комманд: http://www.ipnom.com/ClearCase-Commands/. Это же афигеть можно. А если хоть один параметр к команде неправильный, то эта сука-же тебе ничего не скажет, где ошибка, и иди гадай.

rupert ★★★★★
()
Ответ на: комментарий от hobbit

А сделать то же самое, не перечисляя явно все грохнутые файлы?

Да «кучей» способов! В зависимости от того что значит «грохнутые» файлы.
git checkout --force [<commit>]
git reset --hard [<commit>]

А вообще тебе сюда http://git-scm.com/book/ru/v2

anonymous
()
Ответ на: комментарий от gns

Секьюрити бы джиту не помешало бы добавить... А так верной дорогой идут товарищи! :)

Зачем?!
Тысячи надстроек и пристроек есть, с миллионом возможностей - gitolite gitosis gitorious gerrit fisheye и т.д. и т.д

anonymous
()
Ответ на: комментарий от gns

Секьюрити бы джиту не помешало

«Гиту». Пора бы уже выучить.

И это — тоже. Стоит добавить разграничение доступа к отдельным репозиториям или модулям в одном репозитории или ACL какой-нибудь.

Это решается на уровне ФС или транспорта. К git это никакого отношения не имеет, равно как и шифрование репозиториев.

slovazap ★★★★★
()
Ответ на: комментарий от anonymous

В результате имеем все равно ставим набор инструментов от того же атлассиана (если деньги есть) и «какую-нибудь» VCS или имеем конструктор и геморрой.

gns ★★★★★
()
Ответ на: комментарий от mashina

Симлинки с fuse изобрели?

Какой в пень фьюз, :) там целый MVFS — http://www-01.ibm.com/support/docview.wss?uid=swg21230196

Эхо по треду от неизгладимых впечатлений выглядит каким-то неадекватным, скорее оно похоже на психологическую травму.

Не без этого. CleraCase — хорошая демонстрация принципа, что все можно можно сделать правильно, неправильно и так, как принято делать в армии IBM... :) В общем, оставляет чувство недоумения.

gns ★★★★★
()
Ответ на: комментарий от slovazap

Да я уже понял, что к гиту принято поставлять конструктор... :)

gns ★★★★★
()
Ответ на: комментарий от rupert

Я уже тут кому-то ответил, что в результате получается issue tracker+task tracker и какая-нибудь VCS. Ну тоже подход....

gns ★★★★★
()

Кстати, я правильно понял, что gitorious умер? И как теперь быть? У меня тут из-за этого ебилды *9999 для avidemux сломались, как починить?

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от anonymous

Всё проще, выше уже подсказали - git checkout .

hobbit ★★★★★
()
Ответ на: комментарий от mashina

Поддерживать несколько тулкитов - это одно, а вынужденно переписывать ПО из-за того, что в новой версии тулкита поломали пол-API - немножко другое, IMHO.

qt4 qt5

Это, как я выше писал, как раз можно из одних исходников сделать. Вот qt3+qt4 - придётся либо два раздельных GUI писать, либо условную компиляцию разводить в таких масштабах, что это всё равно будет похоже на два раздельных GUI.

Конечно, этим приходится заниматься, если хочешь, чтобы твоей программой люди пользовались. Но называть это конструктивным занятием я бы не стал. Я сторонник подхода «написал один раз, работает везде».

hobbit ★★★★★
()

А есть ли какой-нибудь официальный репозиторий для RHEL/CentOS-7 откуда можно взять новые версии git? Вроде есть Software Collections, но там только 1.9.

alt-x ★★★★★
()
Ответ на: комментарий от X-Pilot

Там на скриптовых языках только обвязка, в основном для сборки, и ещё на perl для парочки редких команд git. Так что git такой шустрый именно потому что написан на C, без всякого интерпретируемого говна.

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

При наличии установленнного gitg и git-cola раз за разом возвращаюсь к gitk. Дело в скорости загрузки на больших репозиториях, более симпатичном, на мой взгляд, отображении коммитов ну и вообще, удобстве использования.

Хотя, конечно, tk выглядит довольно чужеродно.

AlexM ★★★★★
()
Ответ на: комментарий от Xroft

«Если ты злишся, значит тебе есть чему учиться» (c) Народная мудрость.

anonymous
()
Ответ на: комментарий от anonymous

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

svicer
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.