Состоялся (https://lkml.org/lkml/2016/3/28/436) релиз распределенной системы управления исходными текстами Git 2.8.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/).
По сравнению с прошлым выпуском в новую версию принято 532 изменения, подготовленных при участии 74 разработчиков, из которых 22 впервые приняли своё участие в разработке. Основные (https://github.com/git/git/blob/v2.8.0/Documentation/RelNote...) изменения (https://github.com/blog/2131-git-2-8-has-been-released):- Параллельное извлечение субмодулей из репозитория при выполнении команды "git submodules". Git-репозиторий может включать в себя другие репозитории, оформленные как субмодули, что часто используется для включения в основной проект библиотек и других внешних зависимостей. Основной репозиторий включает информацию о том, какие субмодули включены и какие версии каждого субмодуля используются. Извлечение основного репозитория с больших числом субмодулей (git fetch --recurse-submodules) ранее могло занять много времени, так как субмодули извлекались один за другим. В Git 2.8.0 появилась возможность загружать субмодули в несколько параллельных потоков, число которых определяется через опцию "--jobs" (например, "<font color="#461b7e">git fetch --recurse-submodules --jobs=4</font>").
- Добавлена настройка user.useconfigonly ("<font color="#461b7e">git config --global user.useconfigonly true</font>"), позволяющая запретить совершение коммита без предварительно привязанных к репозиторию идентификационных параметров коммитера (имя и email). При первом коммите, если в конфигурации не заданы параметры user.name и user.email, при установке опции user.useconfigonly будет выведена ошибка. Подобное поведение позволяет исключить публикацию коммитов не под тем именем, в условиях когда разработчик использует разные идентификаторы для разных проектов (например, один email используется для внешних открытых проектов, а дугой для рабочих). Часто, при работе с новым репозиторием разработчик забывает установить в настройках имя и email, что приводит к совершению коммита под нежеланными параметрами, определёнными на основе ранее используемых настроек.- Добавлена большая порция улучшений, направленных на обеспечение комфортной работы с Git на платформе Windows. Многие git-команды, ранее доступные в виде скриптов, переписаны на языке Си. Из проекта Git for Windows перенесены многие специфичные для Windows исправления. В команды, использующие текстовые файлы в качестве входных данных, добавлена поддержка различных схем перевода строки (LF и CRLF);
- Предоставлена возможность отключения фильтров clean и smudge при указании в них пустых строк. Отключение фильтров позволяет значительно сократить время клонирования репозитория, использующего внешнее хранилище бинарных объектов Git LFS;
- Добавлена возможность отследить в каком именно месте был изменён параметр конфигурации (в системных, пользовательских или привязанных к репозиторию настройках). В новом выпуске при выполнении "git config --show-origin" показывается источник изменения.
<font color="#461b7e">
$ git config --show-origin user.name
file:/home/me/.gitconfig Me Myself
</font>- Для диагностики проблем с концом строке добавлена новая команда "git ls-files --eol FILENAME":
<font color="#461b7e">
$ git ls-files --eol README.md screenshot.png
i/lf w/lf attr/ README.md
i/-text w/-text attr/ screenshot.png
</font>
- В команде "git ls-remote" обеспечен вывод ветки, используемой в удалённом репозитории по умолчанию:<font color="#461b7e">
$ git ls-remote --symref origin HEAD
ref: refs/heads/master HEAD
db6696f653b917509dac1ac13b922e12773a84ff HEAD
</font>- Прекращена поддержка транспорта "rsync://" при выполнении "git clone", который достаточно давно находится в неработоспособном виде и, судя по отсутствию сообщений о проблемах, невостребован пользователями;
- Внесены изменения и чистки, призванные избежать возникновения проблем, подобных критической уязвимости (https://www.opennet.ru/opennews/art.shtml?num=44068) CVE-2016-2324, исправленной в выпусках 2.4.11, 2.5.5 и 2.6.6 и 2.7.4.
URL: https://lkml.org/lkml/2016/3/28/436
Новость: https://www.opennet.ru/opennews/art.shtml?num=44125
> добавлена поддержка различных схем перевода строки (LF и CRLF);Шик, блеск!
>> добавлена поддержка различных схем перевода строки (LF и CRLF);
> Шик, блеск!Пользователи Майкрософт должны страдать. Гуманизм и самоотверженное костыляние разработчиков git-а просто удивительны. Неужели среди вендузятников есть разработчики?!
* Many commands that read files that are expected to contain text
that is generated (or can be edited) by the end user to control
their behavior (e.g. "git grep -f <filename>") have been updated
to be more tolerant to lines that are terminated with CRLF (they
used to treat such a line to contain payload that ends with CR,
which is usually not what the users expect)* The low-level merge machinery has been taught to use CRLF line
termination when inserting conflict markers to merged contents that
are themselves CRLF line-terminated.
Ога под винду софта эдак раз в 5000 больше, его барабашки пишут, или он сам пишется наверно...
> его барабашки пишут,
> или он сам пишется наверно...Наверное сам – или кто-то запрещал страдающим самим сделать патч? o_O
«Микрософта», алё!
> «Микрософта», алё!Нет. Полегче с нарциссизмом.
> «Микрософта», алё!Здесь 2 ошибки в слове «Некрософта».
А количество оптимизаторов реестра стремится к бесконечности.
Оптимизация реестра? Вполне успешно выпаривают дефрагментаторы для нтфс на ССД, а особо продвинутые -- для оперативной памяти!
Школьник, открой исходники которые компилятся под винду, в крайнем случаее, зайди в "папку" Program File/Git и посмотри что у тебя там лежит.
> Неужели среди вендузятников есть разработчики?!И в дерьме встречаются жемчужины.
>> среди вендузятников
> И в дерьмеAchievement unlocked: ЧСВ over 9000!
Илита уже переписала центр приложения для убунты, портаж, днф и еще кучу софта? Или невместно непризнанным гениям таким не занимаються?
>> Неужели среди вендузятников есть разработчики?!
> И в дерьме встречаются жемчужины.Так то ж жемчужины (их проткнут эппловским инструментом и сделают бусики), а не разработчики.
"git config --global user.useconfigonly true"Вот этого точно три года ждал!
Кстати, да. Бывали конфузы, когда светились "не то" имя и "не тот" емэйл.
Чем был плох rsync?
Всем был пох rsync.
> Чем был плох rsync?Очевидно же, что он мешал. Вендузятникам костылять git.
>> Чем был плох rsync?
> Очевидно же, что он мешал. Вендузятникам костылять git."git по rdp не умеет. Индусы переживают!"
B) ...https://www.opennet.ru/openforum/vsluhforumID3/105139.html#20
Как можно Git сравнивать с Rsync?
Тем, что «достаточно давно находится в неработоспособном виде и, судя по отсутствию сообщений о проблемах, невостребован пользователями».
Его не было.
И никто этого не замечал.
По пути systemd идут разработчики...
системдэ это особый случай, даже ядру Linux до него еще далеко
лет пять назад были мощнейшие холивары на тему Git vs SVN vs Mercurial) эх были времена...
Сейчас уже просто все ясно, вот и прекратились:
svn - для геронтофилов и мазохистов, git - для любителей "ассемблера от SCM" и покурить маны годик-другой, или тех, кто не может без гитхаба, hg - для тех, кому просто нужно работать без проблем. Эти категории редко пересекаются, поэтому и сраться особо некому.
> Сейчас уже просто все ясно, вот и прекратились:
> svn - для геронтофилов и мазохистовВиндоуз-"профессионалы" коммитят фильмы и икзешники. Это неадо, свежо и современно.
>, git - для любителей "ассемблера от SCM" и покурить маны годик-другой, или тех, кто не может без
Ну почему ж, виндоуз-"профессионалы" костылят и его, как могут: CRLF-ы воркараудят, тесты отключают, котрые виндовые ФС и ядро нунимогут, кеши каких-то майкрософтовских креденшалов запиливают.
Кипит работа по "очеловечиванию", чтоб "для всех"! Вот-вот уже.
> Эти категории редко пересекаются, поэтому и сраться особо некому.
Да. Скучаем. Ждём.
> Сейчас уже просто все ясно, вот и прекратились:
> svn - для геронтофилов и мазохистов, git - для любителей "ассемблера от
> SCM" и покурить маны годик-другой, или тех, кто не может без
> гитхаба, hg - для тех, кому просто нужно работать без проблем.
> Эти категории редко пересекаются, поэтому и сраться особо некому.А hg разве кто-то использует? Он же на питоне.
Всякие двухголовые типы.
> Всякие двухголовые типы.А также эстонци. Пиитоон нее таармаазиит.
> А hg разве кто-то использует? Он же на питоне.https://github.com/git/git/search?l=python
Не смущает Ваши религиозные чуЙства?
Это вспомогательные редко используемые инструменты, вероятно что активные разработчики просто очень редко ими пользуются или вообще не пользуются и поэтому отложили их переписывание на Си в долгий ящик.
> Это вспомогательные редко используемые инструменты, вероятно что активные разработчики
> просто очень редко ими пользуются или вообще не пользуются и поэтому
> отложили их переписывание на Си в долгий ящик.Ага, а в hg только хардкор^W питон, а в гите только си!
Да и вообще – никто же hg не использует! И правда, куда там всяким фейсбукам
https://code.facebook.com/posts/218678814984400/scaling-merc...
nginx-ам https://trac.nginx.org/nginx/browser
или мозиллам https://developer.mozilla.org/en-US/docs/Mozilla/Developer_g...
до уровня Анонимных Экспертов!
Правда, тут пара таких вроде не так давно уже облажалась, сперва не сумев написать более быстрый аналог питоно-кода на си, а затем и слив окончательно по скорости … Но это были наверняка неправильные анонимы! )
>Да и вообще – никто же hg не использует!Так и есть.
>И правда, куда там всяким фейсбукам
>nginx-ам
>или мозилламКак-то жидковато по сравнению с аналогичным списком у git, в фейсбуке какого только крапа не использовали, лучше и не вспоминать. А из Mozilla так и вообще всякое сомнительное прёт бурным потоком, то какие-то проприетарные сервисы встраивают в браузер, то пихают средства для web-разработчиков в браузер, то переписывать на каком-то убогом rust собираются.
>написать более быстрый аналог питоно-кода на си
Слишком толсто, python совсем уж убог в плане скорости, так что такое невозможно даже теоретически.
>>Да и вообще – никто же hg не использует!
> Так и есть.
> в фейсбуке какого
> только крапа не использовали, лучше и не вспоминать. А из Mozilla
> так и вообще всякое сомнительное прёт бурным потоком, то какие-то проприетарные
> сервисы встраивают в браузер, то пихают средства для web-разработчиков в браузер,
> то переписывать на каком-то убогом rust собираются.Оперативно сруливаем с темы? Речь, как бы, о "системе управления исходными текстами".
> Слишком толсто, python совсем уж убог в плане скорости, так что такое
> невозможно даже теоретически.Ну, Анонимные Эксперты и не такие сказки былью делают – они же на полном серьезе считают, что достаточно "написать на Волшебном и Божественном Си" и все будет пучком. А если нет, то … в общем, Анонимым Танцорам вечно что-то мешает – то VCS не правильный, то ЯП, то еще что-то )
>Оперативно сруливаем с темы? Речь, как бы, о "системе управления исходными текстами".Это вы про себя? Речь именно о git и hg, и о том что hg к вашему сожалению безнадёжно проигрывает.
>достаточно "написать на Волшебном и Божественном Си" и все будет пучком
Вот и до Red Hat с их DNF начало доходить что Python убог и надо отказаться от него в пользу Си, чтобы не выглядеть совсем уж лузерами по сравнению с быстрым дебиановским apt.
> Это вы про себя? Речь именно о git и hg, и оНу да:
>> в фейсбуке какого только крапа не использовали
>> А из Mozilla так и вообще всякое сомнительное прёт бурным потоком,конечно же речь именно о hg!
> том что hg к вашему сожалению безнадёжно проигрывает.
Внимание! Ванга в треде! Все одеваем шапочки из фольги и – в сад!
>>достаточно "написать на Волшебном и Божественном Си" и все будет пучком
> Вот и до Red Hat с их DNF начало доходить что Python
> убог и надо отказаться от него в пользу Си, чтобы не
> выглядеть совсем уж лузерами по сравнению с быстрым дебиановским apt.И опять сруливание с темы … впрочем, ничего нового.
Да уж тяжёлая у тебя работа, пропагандировать никому не нужное УГ на безбожно тормозящем Pytnon.
>конечно же речь именно о hg!У тебя что причинно-следственные связи совсем не работают, речь о том что hg выбирают проекты у которых в поведении и планах творится чёрт знает что, поэтому раз уж такие проекты сомнительной адекватности сделали выбор в пользу hg то это свидетельствует о качестве целевой аудитории hg.
> Оперативно сруливаем с темы? Речь, как бы, о "системе управления исходными текстами".Это ты срулил с темы. Назвал три проекта и жидко обocpaлcя, о том что всё остальное на git подзабыв. Ну и да, https://www.openhub.net/repositories/compare уже кидали.
> Ну, Анонимные Эксперты и не такие сказки былью делают – они же
> на полном серьезе считают, что достаточно "написать на Волшебном и Божественном
> Си" и все будет пучком.Не так. От того что приложение написано на C хорошим оно не становится, но вот от того что написано на питоне - гoвном становится гарантированно.
>> Оперативно сруливаем с темы? Речь, как бы, о "системе управления исходными текстами".
> Это ты срулил с темы.Как у тебя бомбит, когда тебя игнорят )
> Назвал три проекта и жидко обocpaлcя, о
Обделался тут как раз некий "hg кто-то использует?"
Ну да, оказалось фейсбуки и мозиллы с нджинксами и openjdk не в счет и поэтому считай что никто!
Так что очередные увиливание и перевод стрелок не удались.> том что всё остальное на git подзабыв.
> Ну и да, https://www.openhub.net/repositories/compare
> уже кидали.А там, походу, вообще рулит SVN. Значит git хуже svn, так ведь?
> Не так. От того что приложение написано на C хорошим оно не
> становится, но вот от того что написано на питоне - гoвном
> становится гарантированно.Анонимным Танцорам, как всегда …, а так они ого-го, всем бы показали!
В меркуриале критичные части реализованы на си.
Субъективно - он медленнее совсем чуточку, хотя репозитории у меня помельче, чем kernel :-)Пользуюсь и меркуриалом, и гитом (где как сложилось), принципиальной разницы нет вообще. Все эти холиворы - ни о чем.
> Пользуюсь и меркуриалом, и гитом (где как сложилось), принципиальной разницы нет вообще.
> Все эти холиворы - ни о чем.Возьми проект уровня ядра или FreeBSD, и посмотри на своё "чуть-чуть".
hg.mozilla.org побольше freebsd будет, вполне нормально работает все.
> Субъективно - он медленнее совсем чуточкуО, вот чувствуется терминология не школьника, а реального аналитика!
> https://github.com/git/git/search?l=python
> Не смущает Ваши религиозные чуЙства?Мы в состоянии набить в поиске lang:C, поэтому не смущает. Гадюк - в террариум.
> hg - для тех, кому просто нужно работатьДа, аплогеты гвидобейсика - они гов^Wпросторабочие.
> svn - для геронтофилов и мазохистов, git - для любителей "ассемблера от
> SCM" и покурить маны годик-другой,Не плакай, для самых маленьких в свежих студиях git поддерживается.
> hg - для тех, кому просто нужно работать без проблем.
Hg все, на него основной разработчик забил. Работа без проблем, говорите?
> git - для любителей "ассемблера от SCM" и покурить маны годик-другой, или тех, кто не может без гитхаба, hg - для тех, кому просто нужно работать без проблемДа что ты? Только на деле почему-то получается что "работающих" раз-два и обчёлся, все только маны курят: https://www.openhub.net/repositories/compare. Смиритесь, git как простой и эффективный инструмент выиграл, а поделка в которой без документации с её мультихедами и сортами веток действительно не разобраться осталась уделом извращенцев. Даже питонщики уже на git.
> Даже питонщики уже на git.А сами питонщики в курсе?
https://www.python.org/dev/peps/pep-0481/
> Status: Draft
> Type: Process
> Created: 29-Nov-2014
LFS -- будут (собираются вообще?) включать во встроенные возможности GIT ?
> LFS -- будут (собираются вообще?) включать во встроенные возможности GIT ?Вот Linux From Scratch -- это точно к культу зюстем-дэ.
Есть же 2 версии LFS'а - как с systemd, так и без. Я юзаю без systemd. А вот в инструментах целые операционки не нужны, да (другой вопрос, что об этом могут мечтать виндузятники, у которых нет доступа к линуксовой консоли). И, вообще, тарболы для исходников надёжнее.
Всё, что вы описали - это про циско.
- Skype-driven development(от перфорса хотелось блeвaть, я пересылал по скупому тарболлы, но те, кто на вантузе - предпочитали зипы).
- Во все свои рецепты я запиливал прогон всех файлов через dos2unix. У остальных без этого ничего не работало.
У проприетарной компании и условия работы парашные, как будто это новость.
Large File Storage здесь. Пока доставляю отдельно.
> Large File Storage здесь. Пока доставляю отдельно.#>>Виндоуз-"профессионалы" коммитят фильмы и икзешники. Это не-адо, свежо и современно.
Скорее бы уже, а то как же мы, болезные, без _облачного_ гитхабикового FTP-то для бинарников внутри распределённо-SCM-ного git-a-то.
Ту же графику к проектам тоже как-то хранить/версионировать надо, как ни странно. А размерчики там бывают приличные.
> git fetch --recurse-submodules --jobs=4джва года ждал
>>Параллельное извлечение субмодулей из репозиторияМои молитвы были услышаны!
Молитвой и багрепортом можно добиться гораздо большего, чем просто молитвой.
> Молитвой и багрепортом можно добиться гораздо большего, чем просто молитвой.Полностью согласен с вами! Добавлю от себя: Ровно того же самого, что и просто багрепортом.
Это смотря какие молитвы. Если молитвы сопровождаются человеческими жертвами...
> Это смотря какие молитвы. Если молитвы сопровождаются человеческими жертвами...Как показал пример Рейзера, это начинает мешать отправке патчей...
Багрепортом и пачем можно добиться гораздо большего, чем просто багрепортом.
> Прекращена поддержка транспорта "rsync://" при выполнении "git clone",Классно, что когда докачка - это уже давным давно само собой разумеющаяся вещь, git clone её не умеет. (Про rsync не знал.)
>> Прекращена поддержка транспорта "rsync://" при выполнении "git clone",
> Классно, что когда докачка - это уже давным давно само собой разумеющаяся
> вещь, git clone её не умеет.Для тех, кто в Китае повторяем: http://git.661346.n2.nabble.com/How-to-resume-broke-clone-td... это Вы не умеете, учитесь.
Для тех, кто в Китае повторяем: http://git.661346.n2.nabble.com/How-to-resume-broke-clone-td... это Вы не умеете, учитесь.
И больше не повторяйте глупостей.
> (Про rsync не знал.)
Ничего не потерял!
> GIT_SMART_HTTP=0Ну если для докачки нужно делать SMART=0, то HTTP в git какой-то совсем не smart.
>> GIT_SMART_HTTP=0
>нужно делать SMART=0Это ж эспешели фор ю.
>какой-то совсем не smart.
Ну кривизна же, да ещё и прибитая к HTTP. А с ssh как быть? Правильно, никак.
> Ну кривизна же, да ещё и прибитая к HTTP. А с ssh
> как быть? Правильно, никак.Попросить у Тэо докачки в scp. Чего не понятно-то? Ну, прямо как SMART=0.