The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск распределенной системы управления исходными текстами Git 2.7.0

05.01.2016 10:26

После трёх месяцев разработки представлен релиз распределенной системы управления исходными текстами Git 2.7.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, LibreOffice, Systemd, X.Org, Wayland, Mesa, Gstreamer, Wine, Debian, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP, Xen, Minix.

По сравнению с прошлым выпуском в новую версию принято 539 изменений, подготовленные при участии 81 разработчика, из которых 26 впервые приняли своё участие в разработке. Основные изменения:

  • Реализация нейтральной схемы заданий начальных и конечных версий в "git bisect". Изначально, так как "git bisect" создавался для выявления ревизии, в которой возникло регрессивное изменение, заведомо рабочая версия помечалась ключём "good", а версия в которой проявляется проблема - "bad". Подобное наименование вызывает замешательство при использовании "git bisect" для поиска коммита вызвавшего изменения, не связанные с ошибками, например, для выявления ревизии в которой появилась новая функциональность или была исправлена ошибка.

    Для того чтобы исключить двойное трактование в git 2.7 представлена новая схема пометки начальной и конечной точек для рецензирования: конечная точка теперь может помечаться ключом "old" (вместо good), а начальная - "new" (вместо bad). Кроме того, имена ключей можно переопределить при помощи опций "--term-old" и "--term-new". Например, при поиске момента появления проблемы с производительностью, замеченной в ветке master, но отсутствующей в v4.2, можно выполнить:

    
       git bisect start --term-old=fast --term-new=slow
       $ git bisect fast v4.2
       $ git bisect slow master
    
  • В "git push" добавлена возможность определения базовой конфигурации опции "--recurse-submodules". Например, чтобы каждый раз не запускать "git push --recurse-submodules=on-demand origin" можно внести изменения в конфигурацию по умолчанию - "git config push.recurseSubmodules on-demand", после чего выполнять "git push origin" не заботясь о субмодулях. Для временного отключения сохранённых параметров в командной строке можно указать "--no-recurse-submodules";
  • Расширение возможностей команды "git worktree", позволяющей создать несколько рабочих копий, привязанных к одному локальному Git-репозиторию. В новом выпуске представлена новая команда "git worktree list", позволяющая просмотреть рабочие копии текущего репозитория и доступные в них ветки. Появилась возможность одновременного создания разных сеансов "git bisect" для разных рабочих копий, созданных через "git worktree add". Добавлена поддержка клонирования из любой привязанной рабочей копии. Улучшена поддержка субмодулей для рабочих копий;
  • В "git p4", прослойку для помещения и извлечения изменений между Git и репозиториями Perforce, добавлена поддержка хранилища больших файлов LFS ("Git Large File Storage"). Новая возможность позволяет сохранять полученные из Perforce большие файлы (например, мультимедийные материалы) отдельно от основного Git-репозитория, чтобы избежать чрезмерного расходования дискового пространства;
  • Проведена унификация команд для вывода ссылок. В Git предлагается три разных способа просмотра списков ссылок: git branch для вывода веток, git tag для вывода тегов и git for-each-ref для вывода ссылок на произвольные объекты. Проблема в том, что каждая из этих команд имеет свои особенности и отличается на уровне опций. В Git 2.7 для всех из этих команд предложен единый набор базовых опций, параметров форматирования вывода и сортировки. Например, добавлены следующие общие опции:
    • --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 улучшена работа на системах с экранами высокого разрешения (highDPI);
  • Устранены уязвимости: целочисленное переполнение в коде оценки изменений (diff) и неограниченное рекурсивное извлечение субмодулей. Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0.


  1. Главная ссылка к новости (https://lkml.org/lkml/2016/1/4...)
  2. OpenNews: В Git устранено несколько уязвимостей
  3. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.6.0
  4. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.5.0
  5. OpenNews: В Launchpad появилась экспериментальная поддержка Git
  6. OpenNews: Выпуск GitLab 8.3 и подкаст с основателем проекта
Лицензия: CC-BY
Тип: Программы
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (28) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 10:37, 05/01/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    С этим git bisect old/new ещё больше запутали, только привык к bad/good. Лучше бы yes/no сделали, было бы более логично.
     
     
  • 2.19, SysA (?), 13:58, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > С этим git bisect old/new ещё больше запутали, только привык к bad/good.
    > Лучше бы yes/no сделали, было бы более логично.

    Перечитай еще раз статью, там есть: '...имена ключей можно переопределить при помощи опций "--term-old" и "--term-new"' - специально для тебя! :)

     
  • 1.3, Какаянахренразница (ok), 10:59, 05/01/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux,
    > Android, LibreOffice, Systemd, X.Org, Wayland, Mesa, Gstreamer, Wine, Debian,
    > DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL,
    > VideoLAN, PHP, Xen, Minix.

    Добавьте Python[1]. И ещё: уберите Minix. При всём уважении к Танненбауму, Миникс можно закапывать.

    [1] https://www.opennet.ru/opennews/art.shtml?num=43619

     
     
  • 2.10, Ph0zzy (ok), 11:57, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    закапывать миникс?
     
     
  • 3.11, Joe (??), 12:34, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, также как и все учебные материалы и книги, без обид но они все уже устарели)))))))))
     
     
  • 4.12, Какаянахренразница (ok), 13:02, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Да, также как и все учебные материалы и книги, без обид но
    > они все уже устарели)))))))))

    Книги по алхимии годятся в качестве учебных? А ведь когда-то они считались непреложной истиной.

    В качестве учебного пособия Миникс, наверное, ещё можно использовать. И в качестве музейного экспоната тоже. Но в качестве примера активного опенсорс проекта, использующего git, Миникс совсем не фонтан. Без обид.

     
  • 3.13, Какаянахренразница (ok), 13:03, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > закапывать миникс?

    Не хотите закапывать -- засушИте и отнесите в антикварную лавку.

     
  • 2.16, Igor (??), 13:35, 05/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Minix3 вполне жива!
     
  • 2.35, Stax (ok), 15:47, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Добавьте Python[1].

    Тут список "разрабатываемых". Python разрабатывается в hg, насчет гитхаба пока только PEP с планами выпустили, а сам переход еще даже толком планировать не начали.

     
  • 1.21, myhand (ok), 00:16, 06/01/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Расширение возможностей команды "git worktree"

    Мне одному кажется как эта штука обрастает рюшечками, которые
    дублируют друг друга по нескольку раз?

    Вот зачем это, когда есть git stash?  (Или наоборот, зачем этот stash теперь?)

     
     
  • 2.22, Ytch (ok), 01:31, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот зачем это, когда есть git stash?

    Ну например, как пишут сами разработчики (https://git-scm.com/docs/git-worktree):

    > You might typically use git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it.

    То есть, когда изменения настолько глобальны и запутанны, что stash использовать уже страшновато )))

    > Или наоборот, зачем этот stash теперь?

    А для "условно простых" случаев в плане изменений (но громоздких, например, worktree) - stash получше (полегче, пошустрей, структурированней может быть).

    Для условно небольших репозиториев и вовсе при помощи clone ненапряжно сделать тоже самое.

    Не так уж, имхо, это и плохо иметь несколько способов.

    P.S. А так можно ж потенциально ещё и наборы stash-ей в разных worktree одновременно! Чтоб уж путаница, так настоящая!!! )

     
     
  • 3.24, myhand (ok), 02:08, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну например, как пишут сами разработчики

    "Ниче не понял" (ц)

    Как именно все должно быть поломано, чтобы git stash не сработал и
    с какого это вдруг теперь не считается багом?

    > что stash использовать уже страшновато )))

    Так докатимся до того, что любую команду git будешь бояться запускать.

    > Не так уж, имхо, это и плохо иметь несколько способов.

    Но не до фанатизма ж!

     
     
  • 4.26, Ytch (ok), 03:15, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Как именно все должно быть поломано, чтобы git stash не сработал и
    > с какого это вдруг теперь не считается багом?

    Откуда мне знать? ) Так "пишут сами разработчики" - я лишь привел цитату их же собственного примера применения из официального man-а. Сам я не сталкивался с такими поломками (пока, по-крайней мере).

    >> что stash использовать уже страшновато )))
    > Так докатимся до того, что любую команду git будешь бояться запускать.

    Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...

    "such a state of disarray that you don’t want to risk disturbing any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать" вполне, имхо, тянет на шуточный короткий перевод типа "ссыкотно +смайл", что в чуть более культурном варианте звучит как "страшновато )))". Не вот же уж "ужас-ужас".

     
     
  • 5.28, myhand (ok), 03:57, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Откуда мне знать? ) Так "пишут сами разработчики"

    Пишут так, что кондратий скоро хватит при прочтении.

    >>> что stash использовать уже страшновато )))
    >> Так докатимся до того, что любую команду git будешь бояться запускать.
    > Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...

    Ну, выше была тоже она, родимая.  Однако, сказка - ложь, да...

    > "such a state of disarray that you don’t want to risk disturbing
    > any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать"

    Доктор, и как мне после этого git stash вообще использовать?

    Не, действительно интересно что конкретно имелось в виду.

     
     
  • 6.29, Ytch (ok), 04:34, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не, действительно интересно что конкретно имелось в виду.

    Вообще это похоже немного на трогательную заботу о тех у кого опыт с другими VCS (где ничего подобного stash либо просто нет либо вообще нетипичная практика) сильно превышает опыт с git. В тех VCS сложно придумать что-то кроме как вытащить working tree куда-нибудь в другое место, поговнофиксить там, по окончании всё грохнуть и продолжить работу. А в стрессах старые привычки никуда не денешь. А тут прям привычный workflow.

    И у меня пару раз бывало подобное. После серии бесчеловечных экпериментов "отвлекся" на срочную работу, потом на очень срочную, потом на следующую и так далее... Так тихо и незаметно прошло несколько месяцев. И тут надо че-то подправить и, как это бывает, "позавчера уже должно было быть сделано". Кто бы помнил что там и в каком состоянии осталось и вообще зачем затевалось...

    Добавляем к такому вот дурацкому рабочему процессу ещё и lack of git experience и понеслось...

     
  • 2.23, anonymous (??), 01:53, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь stash это совсем другое.
    С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.

    Типа
    git branch worktree_01 <commit>
    git clone --depth 1 -b worktree_01 file://<path>

    Только я тож не совсем понимаю зачем это - кто-то пришел с флешкой "А дай-ка мне версию 123"?
    А ты ему "git worktree add <флешка> <commit>

     
     
  • 3.25, Ytch (ok), 03:01, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Только я тож не совсем понимаю зачем это

    Например (немного фантазирую), может иногда оказаться удобным чтоб "визуально" сравнить дерево файлов с разных веток (особенно если между ними было много переименований файлов/добавлений файлов/удалений файлов/переносов в поддиректории и т. п.) - просто чтоб наглядно и быстро оценить отличия именно в структуре файлов и их расположениях в поддиректориях. Просто быстро глянуть (может на какие-то определенные поддиректории или ещё как). В общем, где глазом оценить проще и быстрей чем всякими могучими diff-ами и т. п. Как вариант.

     
  • 3.27, myhand (ok), 03:47, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Но ведь stash это совсем другое.
    > С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.

    git stash # спасаем
    git checkout -b worktree_01 <commit>  # достаем

    ы?

     
     
  • 4.36, anon007 (?), 16:49, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что "ы"?

    и git stash и git checkout перезапишут вам рабочую директорию.

    P.S. тут http://git-scm.com/book/en/v2 (на русском http://git-scm.com/book/ru/v2)
    довольно хорошая книга о git.

     
     
  • 5.38, myhand (ok), 17:38, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > и git stash и git checkout перезапишут вам рабочую директорию.

    git stash - _сохранит_ текущую рабочую директорию.

    Тут просто кто-то не совсем четко поставил задачу.  А так, отличия stash и
    worktree - конечно очевидны в случае если вы не хотите сразу продолжить работу
    над обеими версиями рабочей директории (например, вы держите открытые файлы
    для "старой" версии, там еще тесты выполняются и т.п.)

     
  • 3.31, Andrey Mitrofanov (?), 10:31, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Но ведь stash это совсем другое.
    > С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей
    > рабочей директории.
    > Типа
    > git branch worktree_01 <commit>
    > git clone --depth 1 -b worktree_01 file://<path>
    > Только я тож не совсем понимаю зачем это - кто-то пришел с

    Не, это облегченный локальный git slone --share! (наверное. я ж тоже не понимаю зачем. идём от "добавление уровня индирекции решает"(1)... ищем ту проблему!)  Так вот, получается же клон+чекаут вообще без директории ./.git/ в нём, да? [[[Надо смотреть, как они индексы чекау^Wворкдиров разделяют при одной .git/]]]  Можно использовать для билдов ы отдельном дереве, которое выбрасывать сразу после  -- rm--rf вместо make clean. Да, для короткоживущих ч-о не сильно проще или лучше share-клона. Наверное. Или, например, отдельные долгоживущие ч-о & ветка с фич-девелопментом без мерджа/публикации (пока~) в "master"/внеш.мир.

    *(1) да, и усложняет.

    > флешкой "А дай-ка мне версию 123"?
    > А ты ему "git worktree add <флешка> <commit>

    git clone где://то.там/должен/бы/знать/уже

    Кого-кого, а _друзей_ надо держать в курсе! Особенно того, что клон-ч-о +точно+ [да, должен быть!] быстрее "прийти" и "флэшки".

     
     
  • 4.32, Andrey Mitrofanov (?), 11:48, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Полистал https duckduckgo com q why git worktrees are needed пару ответов на ... текст скрыт, показать
     
     
  • 5.33, myhand (ok), 14:32, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
    > w.d. = новый stash с чекаутами и грязнымиB) деревьями.

    Заметьте, не я это предложил!

     
     
  • 6.34, Andrey Mitrofanov (?), 15:38, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
    >> w.d. = новый stash с чекаутами и грязнымиB) деревьями.
    > Заметьте, не я это предложил!

    Не осилил, или я опять невнятен?

    Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще и быстрее. И, вероятно, после того, как закончат вкрячивать этот +1 слой индирекции во все-все "основные" функции, git-stash объявят устаревшим и выкинут.

    Ключевые, чтоб понятнее: больше, дальше, сильнее, но пока ещё не [на 100%] тут.

     
     
  • 7.37, anon007 (?), 17:12, 06/01/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще
    > и быстрее.

    А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные ветки").
    Пока параллельно, например, собираются версии v1, v2, v3
    можно редактировать файлы в версии dev.

     
     
  • 8.42, Аноним (-), 15:54, 11/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные
    > ветки").
    > Пока параллельно, например, собираются версии v1, v2, v3
    > можно редактировать файлы в версии dev.

    Верно, я с самого начала так git-worktree и воспринял. Мне регулярно приходится делать как раз подобное. Непонятки местных комментаторов и сравнение со stash меня удивляют.

     
     
  • 9.43, Andrey Mitrofanov (?), 17:21, 11/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> А мне кажется :-) что git-worktree это "расширение" возможностей веток
    >Непонятки местных комментаторов и сравнение со stash меня удивляют.

    Вкус фломастеров. Кто мы такие, чтобы развевать ваши фантазии?

    <Впрочем.> Ветки, неожиданно, были "параллельными" и до того.

    На локалхостике их пришлось бы "обернуть" избыточными теперь (и stash -- туда же) git-clone-ами и приседаниями с push-pull-ами  --  именно в случае одновременно живучих чекаутов.

     
  • 4.41, Аноним (-), 15:51, 11/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это сообщение отформатировано настолько безумно, что я ничего не понял.
     
     
  • 5.44, Andrey Mitrofanov (?), 17:22, 11/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Это сообщение отформатировано настолько безумно, что я ничего не понял.

    А промолчал бы -- сошёл за умного.

     
  • 1.39, Аноним (-), 04:42, 08/01/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0

    $ git --version
    git version 1.9.1

     
     
  • 2.40, myhand (ok), 11:51, 08/01/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0
    > $ git --version
    > git version 1.9.1

    А некоторые племена на Земле используют каменные топоры...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor