После трёх месяцев разработки представлен (https://lkml.org/lkml/2016/1/4/739) релиз распределенной системы управления исходными текстами Git 2.7.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st.../), Android (https://android.googlesource.com/), LibreOffice (http://cgit.freedesktop.org/libreoffice), Systemd (http://cgit.freedesktop.org/systemd), X.Org (http://cgit.freedesktop.org/xorg), Wayland (http://cgit.freedesktop.org/wayland), Mesa (http://cgit.freedesktop.org/mesa/), Gstreamer (http://cgit.freedesktop.org/gstreamer), Wine (http://source.winehq.org/git/wine.git), Debian (http://anonscm.debian.org/gitweb), DragonFly BSD (http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary), Perl (http://perl5.git.perl.org/perl.git), Eclipse (http://git.eclipse.org), GNOME (http://git.gnome.org/browse/), KDE (https://projects.kde.org/projects), Qt (https://code.qt.io/cgit/), Ruby on Rails (https://github.com/rails/rails), PostgreSQL (http://git.postgresql.org/gitweb/), VideoLAN (http://git.videolan.org), PHP (http://git.php.net/), Xen (http://xenbits.xen.org/gitweb/), Minix (http://git.minix3.org/).
По сравнению с прошлым выпуском в новую версию принято 539 изменений, подготовленные при участии 81 разработчика, из которых 26 впервые приняли своё участие в разработке. Основные (https://github.com/git/git/blob/v2.7.0/Documentation/RelNote...) изменения (https://github.com/blog/2094-new-year-new-git-release):- Реализация нейтральной схемы заданий начальных и конечных версий в "git bisect". Изначально, так как "git bisect" создавался для выявления ревизии, в которой возникло регрессивное изменение, заведомо рабочая версия помечалась ключём "good", а версия в которой проявляется проблема - "bad". Подобное наименование вызывает замешательство при использовании "git bisect" для поиска коммита вызвавшего изменения, не связанные с ошибками, например, для выявления ревизии в которой появилась новая функциональность или была исправлена ошибка.
Для того чтобы исключить двойное трактование в git 2.7 представлена новая схема пометки начальной и конечной точек для рецензирования: конечная точка теперь может помечаться ключом "old" (вместо good), а начальная - "new" (вместо bad). Кроме того, имена ключей можно переопределить при помощи опций "--term-old" и
"--term-new". Например, при поиске момента появления проблемы с производительностью, замеченной в ветке master, но отсутствующей в v4.2, можно выполнить:<font color="#461b7e">
git bisect start --term-old=fast --term-new=slow
$ git bisect fast v4.2
$ git bisect slow master
</font>
- В "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);
- Устранены уязвимости: целочисленной переполнение (https://github.com/git/git/commit/92cdfd21313c5bf5657d4ac2d3...) в коде оценки изменений (diff) и неограниченное (https://github.com/git/git/commit/f2df3104ce45bc1ee6d7c16f3a...) рекурсивное извлечение субмодулей. Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0.URL: https://lkml.org/lkml/2016/1/4/739
Новость: http://www.opennet.ru/opennews/art.shtml?num=43626
С этим git bisect old/new ещё больше запутали, только привык к bad/good. Лучше бы yes/no сделали, было бы более логично.
> С этим git bisect old/new ещё больше запутали, только привык к bad/good.
> Лучше бы yes/no сделали, было бы более логично.Перечитай еще раз статью, там есть: '...имена ключей можно переопределить при помощи опций "--term-old" и "--term-new"' - специально для тебя! :)
> Из проектов, разрабатываемых с использованием 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. При всём уважении к Танненбауму, Миникс можно закапывать.
закапывать миникс?
Да, также как и все учебные материалы и книги, без обид но они все уже устарели)))))))))
> Да, также как и все учебные материалы и книги, без обид но
> они все уже устарели)))))))))Книги по алхимии годятся в качестве учебных? А ведь когда-то они считались непреложной истиной.
В качестве учебного пособия Миникс, наверное, ещё можно использовать. И в качестве музейного экспоната тоже. Но в качестве примера активного опенсорс проекта, использующего git, Миникс совсем не фонтан. Без обид.
> закапывать миникс?Не хотите закапывать -- засушИте и отнесите в антикварную лавку.
Minix3 вполне жива!
> Добавьте Python[1].Тут список "разрабатываемых". Python разрабатывается в hg, насчет гитхаба пока только PEP с планами выпустили, а сам переход еще даже толком планировать не начали.
> Расширение возможностей команды "git worktree"Мне одному кажется как эта штука обрастает рюшечками, которые
дублируют друг друга по нескольку раз?Вот зачем это, когда есть git stash? (Или наоборот, зачем этот stash теперь?)
> Вот зачем это, когда есть 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 одновременно! Чтоб уж путаница, так настоящая!!! )
> Ну например, как пишут сами разработчики"Ниче не понял" (ц)
Как именно все должно быть поломано, чтобы git stash не сработал и
с какого это вдруг теперь не считается багом?> что stash использовать уже страшновато )))
Так докатимся до того, что любую команду git будешь бояться запускать.
> Не так уж, имхо, это и плохо иметь несколько способов.
Но не до фанатизма ж!
> Как именно все должно быть поломано, чтобы git stash не сработал и
> с какого это вдруг теперь не считается багом?Откуда мне знать? ) Так "пишут сами разработчики" - я лишь привел цитату их же собственного примера применения из официального man-а. Сам я не сталкивался с такими поломками (пока, по-крайней мере).
>> что stash использовать уже страшновато )))
> Так докатимся до того, что любую команду git будешь бояться запускать.Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...
"such a state of disarray that you don’t want to risk disturbing any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать" вполне, имхо, тянет на шуточный короткий перевод типа "ссыкотно +смайл", что в чуть более культурном варианте звучит как "страшновато )))". Не вот же уж "ужас-ужас".
> Откуда мне знать? ) Так "пишут сами разработчики"Пишут так, что кондратий скоро хватит при прочтении.
>>> что stash использовать уже страшновато )))
>> Так докатимся до того, что любую команду git будешь бояться запускать.
> Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...Ну, выше была тоже она, родимая. Однако, сказка - ложь, да...
> "such a state of disarray that you don’t want to risk disturbing
> any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать"Доктор, и как мне после этого git stash вообще использовать?
Не, действительно интересно что конкретно имелось в виду.
> Не, действительно интересно что конкретно имелось в виду.Вообще это похоже немного на трогательную заботу о тех у кого опыт с другими VCS (где ничего подобного stash либо просто нет либо вообще нетипичная практика) сильно превышает опыт с git. В тех VCS сложно придумать что-то кроме как вытащить working tree куда-нибудь в другое место, поговнофиксить там, по окончании всё грохнуть и продолжить работу. А в стрессах старые привычки никуда не денешь. А тут прям привычный workflow.
И у меня пару раз бывало подобное. После серии бесчеловечных экпериментов "отвлекся" на срочную работу, потом на очень срочную, потом на следующую и так далее... Так тихо и незаметно прошло несколько месяцев. И тут надо че-то подправить и, как это бывает, "позавчера уже должно было быть сделано". Кто бы помнил что там и в каком состоянии осталось и вообще зачем затевалось...
Добавляем к такому вот дурацкому рабочему процессу ещё и lack of git experience и понеслось...
Но ведь stash это совсем другое.
С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.Типа
git branch worktree_01 <commit>
git clone --depth 1 -b worktree_01 file://<path>Только я тож не совсем понимаю зачем это - кто-то пришел с флешкой "А дай-ка мне версию 123"?
А ты ему "git worktree add <флешка> <commit>
> Только я тож не совсем понимаю зачем этоНапример (немного фантазирую), может иногда оказаться удобным чтоб "визуально" сравнить дерево файлов с разных веток (особенно если между ними было много переименований файлов/добавлений файлов/удалений файлов/переносов в поддиректории и т. п.) - просто чтоб наглядно и быстро оценить отличия именно в структуре файлов и их расположениях в поддиректориях. Просто быстро глянуть (может на какие-то определенные поддиректории или ещё как). В общем, где глазом оценить проще и быстрей чем всякими могучими diff-ами и т. п. Как вариант.
> Но ведь stash это совсем другое.
> С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.git stash # спасаем
git checkout -b worktree_01 <commit> # достаемы?
Что "ы"?и git stash и git checkout перезапишут вам рабочую директорию.
P.S. тут http://git-scm.com/book/en/v2 (на русском http://git-scm.com/book/ru/v2)
довольно хорошая книга о git.
> и git stash и git checkout перезапишут вам рабочую директорию.git stash - _сохранит_ текущую рабочую директорию.
Тут просто кто-то не совсем четко поставил задачу. А так, отличия stash и
worktree - конечно очевидны в случае если вы не хотите сразу продолжить работу
над обеими версиями рабочей директории (например, вы держите открытые файлы
для "старой" версии, там еще тесты выполняются и т.п.)
> Но ведь 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 где://то.там/должен/бы/знать/уже
Кого-кого, а _друзей_ надо держать в курсе! Особенно того, что клон-ч-о +точно+ [да, должен быть!] быстрее "прийти" и "флэшки".
>> Но ведь stash это совсем другое.
>> Только я тож не совсем понимаю зачем это - кто-то пришел с
> Не, это облегченный локальный git slone --share! (наверное. я ж тоже неПолистал https://duckduckgo.com/?q=why+git+worktrees+are+needed пару ответов на этот вопрос.
http://stackoverflow.com/questions/31935776/what-would-i-use...
?
Судя по всему, "реп-один -- ч-о-много" избавляет от: 1) очистки (uor workdir is not clean) w.d. перед ч-о (или запустить билд, тест, робо-биссект, и в то жк время(!) редактировать и коммитить в рабочей w.d. -- чуть быстрее, чем с клонами? впрочем, там коммиты и пуши не нужны... О! тогда робо-биссект с робо-ребейзами на робо-тестак!!%) И публикация рибейзнутого, чтоб мёном не.); 2) не сташ = у того _нет_ w.d./ч-о (и да, stash не нужен >> w.d. ==ответ неосиляторов stash-а? %) или w-d ==ответ на нЕмощь стэша?); 3) с клоном (независито от --local/--share) всё равно для публикации/мерджа будет нужен push -- а с w.d. "та ветка" уже там... Видна и сравнима "ешё до/совсем без пуша". Наверное. 3.5) Да! Не надо держать в голове, сколько локальных клонов проекта есть -- все w.d. в отдном "флаконе".4!) git битва: апстрим *против* хуба! https://github.com/blog/2042-git-2-5-including-multiple-work...
И да, git-worktree(1):
..."you can simply delete it/"
..."still experimental, and the support for submodules is incomplete."...Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо, w.d. = новый stash с чекаутами и грязнымиB) деревьями. Может, это и есть гл.причина ==замена рудиментарной Ж) quilt-япки. А может, просто (пока?) других применений я (и/или они? никто??) не нашёл.
..."мы не знаем"ТМ -- позовите Джунио?
---Наливай! //ушёд листать архив git ML> понимаю зачем. идём от "добавление уровня индирекции решает"(1)... ищем ту проблему!)
> Так вот, получается же клон+чекаут вообще без директории ./.git/ в
> нём, да? [[[Надо смотреть, как они индексы чекау^Wворкдиров разделяют при однойПосмотрел: в .git/worktrees/*/ кладут "много маленьких .git/-иков. И пляшут вокруг.
> *(1) да, и усложняет.
>> флешкой "А дай-ка мне версию 123"?
>> А ты ему
> git clone где://то.там/должен/бы/знать/уже
> Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
> w.d. = новый stash с чекаутами и грязнымиB) деревьями.Заметьте, не я это предложил!
>> Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
>> w.d. = новый stash с чекаутами и грязнымиB) деревьями.
> Заметьте, не я это предложил!Не осилил, или я опять невнятен?
Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще и быстрее. И, вероятно, после того, как закончат вкрячивать этот +1 слой индирекции во все-все "основные" функции, git-stash объявят устаревшим и выкинут.
Ключевые, чтоб понятнее: больше, дальше, сильнее, но пока ещё не [на 100%] тут.
> Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще
> и быстрее.А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные ветки").
Пока параллельно, например, собираются версии v1, v2, v3
можно редактировать файлы в версии dev.
> А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные
> ветки").
> Пока параллельно, например, собираются версии v1, v2, v3
> можно редактировать файлы в версии dev.Верно, я с самого начала так git-worktree и воспринял. Мне регулярно приходится делать как раз подобное. Непонятки местных комментаторов и сравнение со stash меня удивляют.
>> А мне кажется :-) что git-worktree это "расширение" возможностей веток
>Непонятки местных комментаторов и сравнение со stash меня удивляют.Вкус фломастеров. Кто мы такие, чтобы развевать ваши фантазии?
<Впрочем.> Ветки, неожиданно, были "параллельными" и до того.
На локалхостике их пришлось бы "обернуть" избыточными теперь (и stash -- туда же) git-clone-ами и приседаниями с push-pull-ами -- именно в случае одновременно живучих чекаутов.
Это сообщение отформатировано настолько безумно, что я ничего не понял.
> Это сообщение отформатировано настолько безумно, что я ничего не понял.А промолчал бы -- сошёл за умного.
> Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0$ git --version
git version 1.9.1
>> Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0
> $ git --version
> git version 1.9.1А некоторые племена на Земле используют каменные топоры...