Опубликованы корректирующие выпуски распределённой системы управления исходными текстами Git 2.38.4, 2.37.6, 2.36.5, 2.35.7, 2.34.7, 2.33.7, 2.32.6, 2.31.7 и 2.30.8, в которых устранены две уязвимости, затрагивающие оптимизации при локальном клонировании и команду "git apply". Проследить за выпуском обновлений пакетов в дистрибутивах можно на страницах Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD. Если установить обновление не представляется возможным, в качестве обходных мер рекомендуется избегать выполнения...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58655
Не зря Тео запилил got, ой не зря.
Чем меньше возможностей, тем меньше проблем. Если не умеет вообще ничего, статистически будет более надёжно, но пользоваться этим никто не сможет.
Ну гиту уменьшение функционала не повредит. Много специфичного и малоиспользуемого функционала.
Кому сколько нужно, тот столько и берёт функционала. Остальное отключают.
OpenSSH не даст соврать.
Так got поверх git работает лол. Считай фронтенд просто.
> Так got поверх git работает лол. Считай фронтенд просто.Источник: "Опеннетные сказания и предания о реальном устройстве мира. Том 100501"?
http://gameoftrees.org/got.1.html#CAVEATS
CAVEATSgot is a work-in-progress and some features remain to be implemented.
At present, the user has to fall back on git(1) to perform some tasks. In particular:
Reading from remote repositories over HTTP or HTTPS protocols requires git-clone(1) and git-fetch(1).
Writing to remote repositories over HTTP or HTTPS protocols requires git-push(1).
The creation of merge commits with more than two parent commits requires git-merge(1).
In situations where files or directories were moved around got will not automatically merge changes to new locations and git(1) will usually produce better results.
> At present, the user has to fall back on git(1) to perform some tasks. In particular:может дешевле было перечислить что он все же как-то сам умеет делать? Или там список из нуля пунктов?
>> At present, the user has to fall back on git(1) to perform some tasks. In particular:
> может дешевле было перечислить что он все же как-то сам умеет делать? Или там список из нуля пунктов?Что сказать-то хотел? Что неумение фигачить через обертку HTTP(S) и разруливать экзотические случаи мержа переводит got в статус "фронтенд просто"?
неумение в _основной_ (где, у каких идиотов еще торчит в мир голый git протокол без авторизации в принципе?) способ взаимодействия с внешним миром в сочетании еще и с неумением локально мерж (основу-основ dvcs) обработать - переводит в статус той самой фигни, состоящей из readme.md и CoC.md
Совершенно безопастной но абсолютно никому кроме ЧСВ авторов не нужной.
Вопрос всенарастпереписальщикам - ну и как borrow-checker защитит от логических ошибок этого класса (преждевременная оптимизация)? :)
Успокойся, тут никто не говорил про твой этот борроу-чекер.
Никак.
Как? Освобождается время, нервы и силы на подсчёт байтов, и можно уделять больше ментальных ресурсов на логику в реализации.
Уточните, где там преждевременная оптимизация?
Деды раньше как-то модули в тарах хранили, а внучата сейчас все модули в git репах хранят. Обленились совсем.
Помню вот ещё времена Рюрика...
Ох, и взяли мы тогда в царь-граде тарболлов иноземных, много мирры и умбры, рабов и злата...
В тарах, говорите? А мы в папках!
10k перфокарт в одной таре, и таров этих - не счесть
Не работали, видимо, с перфокартами. Большие проекты хранили на бобинах. А свои проекты, действительно, на перфокартах или перфолентах. 100-200 перфокарт в пакете или рулончик перфоленты, которая четко помещалась в пластиковую коробочку от рыболовных крючков, не особенно обременяли.
Чувак, не хотел бы рушить твой маня-мирок, но 200 перфокарт - это 200 СТРОК.Ахрененные у тебя, смотрю, прожекты были.
А рулончик перфоленты быстро рвался и тоже вмещал очень мало. Обычно на нем держали бинарники которых не очень жалко - в смысле, было с чего еще раз ту ленту вывести.
Магнитные ленты появились сильно позже и то что на них хранили, ни на какую перфоленту бы не влезло вообще. И те быстро вышли из обращения. А вот колоды перфокарт с тысячами этих самых карт, пронумерованных химическим карандашом (не дай Б-же рассыпать!) еще долгонько были в ходу.
> 200 перфокарт - это 200 СТРОК.для студенческого проекта это нормально.
для курсовика по непрофильной специальности тоже.
25% - подключение внешней библиотеки анализа данных,
10% - подключение внешнего файла этих самых данных и т.д.
чувак, это ПЕРФОКАРТЫ, ну какой нах тебе файл? //SYSIN DD * (и да это тоже целая одна карта уже потрачена)Не, для студня 200 штук набить это конечно да, немало, дифур какой оно решало, или еще что такого же рода, несильно сложное и без сложного инпута, пару цифирей прочитать, одну вывести...
> ну какой нах тебе файл?обычный массив данных, на диске. доступ ISAM.
диск оператор смонтирует по заказу.
да ну, кто студенту дисковый пакет даст вообще, даже на время попользоваться?с ними те программы работали, которым перфокарты чемоданами нужно было переносить.
Там да, уже и библиотеки и дисковые пакеты, но оно уже и не в 200 строк обычно нифига было, а как бы запросто и поболее 2000
> да ну, кто студенту дисковый пакет даст вообще, даже на время попользоваться?нам давали. один на поток. только данные были враные, т.к. были собраны через ЦСУ.
ну и GIGO во весь рост.
В некоторых НИИ где пишут ПО для военных спутника примерно так и сейчас хранят.
Несмотря на то что одна из первых систем управления версиями RCS появилась в 1982, в несколько раз раньше чем родилось большинство местных экспертов.
Гит такая странная монстроузная ерунда, как тот OpenSSL, что непонятно как оно вообще работает и не падает на каждый чих.
«Git» и «OpenSSL» тут можно заменить на любой современный софт.
> «Git» и «OpenSSL» тут можно заменить на любой современный софт.Есть софт сломанный на уровне архитектуры. А есть просто плохо реализованный. А есть и нормально в целом.
Git относиться к категории - это нельзя было делать ни при каких обстоятельствах.
Его делали для конкретной цели - как систему контроля для разработки ядра. Со всеми вытекающими. Зачем миллионы мух стали тащить его в свои проекты надо спросить у этих самых мух.
Дрю деволт с тобой бы поспорил https://git.sr.ht/~sircmpwn/shit
> Дрю деволт с тобой бы поспорил https://git.sr.ht/~sircmpwn/shitА чего спорить, про гит и шелскрипт всё написано по ссылке:
How to use - Don't
Предыстория другая: дрю спорил о том что гит на самом деле прост и он реализует его на баше, что собственно он и сделал. Пользоваться понятное дело этим смысла не имеет.
Не, реализовать это может и просто, насколько я помню изначально гит был слеплен большей частью на баше, в этом то и проблема, оно создано чтобы его можно было написать на шел скрипте, а не для того чтобы было удобно пользоваться.
Хранить БД в файловой системе сама по себе идея плохая.
> Не, реализовать это может и просто, насколько я помню изначально гит был
> слеплен большей частью на баше, в этом то и проблема, оно
> создано чтобы его можно было написать на шел скрипте, а не
> для того чтобы было удобно пользоваться.Там просто изначально был низкоуровневый интерфейс, который макаки не осилили. Для них сделали высокоуровневый.
> Хранить БД в файловой системе сама по себе идея плохая.
Почему?
> Почему?Ну как минимум нет нормального языка запросов, всё что сложнее "достань мне файл с таким-то именем" нужно самому на коленке кодить.
Плюс захламление и без того перегруженной ФС.
Проблемы с контролем целостности базы.
Короче зачем переизобретать велосипед когда их на любой вкус и цвет есть.
https://github.com/libgit2/libgit2-backendsопять таки если речь о рабочей копии - почему и не на файлухе?
опять таки если нужно что-то кроме "достань мне файл с таким-то именем" - этим занимается git/субд и кому и что городить?
Бред. Что такое нормальный язык запросов? ФС это уже БД, с присущими ей некоторыми примитивами, как атомарность некоторых операций, целостность данных, индексы для быстрой выборки и кэш. Если под нормальным подразумевается SQL - так это выдумка для реляционных БД. А не все данные реляционные. Я уж молчу про то, что РСУБД это тот ещё монстр поверх ФС, который надо уметь готовить, для нормальных скоростей, что большинство не умеет.
>> Дрю деволт с тобой бы поспорил https://git.sr.ht/~sircmpwn/shit
> А чего спорить, про гит и шелскрипт всё написано по ссылке:
> How to use - Don't
git очень прост, если ты примешь что git это не система контроля версий, а набор специализированных команд для копирования файлов, вычисления diff'ов и накладывания patch'ей.Описанные уязвимости же, это естественное следствие того, что unix'овая файловая система прикидывается деревом, но с завидным постоянством ведёт себя не как дерево, а как ориентированный граф. Человеки они такие, они склонны использовать упрощающие допущения, в процессе своего мышления, и склонны совершать ошибки, применяя упрощающие ситуацию допущения тогда, когда эти допущения неверны. И если ты поощряешь это сверху, то ты получаешь от них бесконечный поток багов.
Поэтому работать надо не с файлами и файловой системой, где есть множество сложностей и неясностей. А с чем-нибудь гораздо более стандартизированным, изолированным, созданным именно для безопасного и надёжного хранения данных. Как насчёт СУБД? Многопоточные не нужны, хватит на мой взгляд и обычного sqlite. Как тебе такая идея?
Ну м.б. до 2Тб ничё будет ... А потом ?
И как это бакапить/восстанавливать ? А если кто-то втуда пишет, а семерым надо из неё читать ? Да ещё мааахонький сбой в метаданных и всех данных как небывало.
Называется фоссиль
> git это не система контроля версий, а набор специализированных команд для копирования файлов, вычисления diff'ов и накладывания patch'ейСобственно я о том-же и пишу.
Это НИКОГДА ненужно было "изобретать".
> Это НИКОГДА ненужно было "изобретать".Если ты предпочитаешь вручную все эти копии делать, отслеживая версии, то это твоё личное дело. Я предпочитаю автоматизировать.
Я предпочитаю контроль версий делать системой контроля версий, а не слепленной на коленке химерой.
и где эта система контроля версий? svn неудобна для работы с _чужими_ проектами, потому что ты не можешь ее клонировать. меркуриал сдох из-за впихона.Как обычно, рыночек и хайп порешали в пользу наиболее уродливого решения.
> и где эта система контроля версий? svn неудобна для работы с _чужими_
> проектами, потому что ты не можешь ее клонировать. меркуриал сдох из-за
> впихона.Фосил есть ещё.
> Как обычно, рыночек и хайп порешали в пользу наиболее уродливого решения.
Отош.
> Фосил есть ещё.используется в одном проекте одного (ок, двух с половиной) автора. Который не принимает патчи.
Ну как-то так себе он "есть". То есть вероятнее всего - снова решение проблем одного-единственного человека, и этот человек - не ты и не я. Проверять, конечно же, буду не раньше чем trac доломают.
оно решало конкретную проблему одного очень самоуверенного и самодовольного персонажа.Который, к прочим недостаткам, обладал тяжелым синдромом утенка и не смог осилить базовое назначение системы контроля версий. Потому что его устраивало /usr/src/linux-0.95 и он никак не мог взять в толк, с чего команды разработчиков отдельных подсистем без конца ноют.
А патчи он принимал elm'ом или что там у него тогда было, вручную просматривая и одобряя только то что в экран влазиет. Именно эту бредятину он себе и автоматизировал.
Потом - другие люди - пытались как-то автоматизировать себе жизнь по другую сторону, чтобы не было хотя бы совсем уж мучительно с этим одаренным взаимодействовать.
в curl найдена уязвимость, не рекомендуется выполнять curl http://xx44.cc.us/coolscript.sh | sudo bash -s
А как же 2.39.1?
https://security-tracker.debian.org/tracker/CVE-2023-22490>vulnerable
классика. В некоммерчеких проектах никто никому ничего не обязан
Наброс не засчитан
Я не понимаю, чем вы недовольны ?? Git никогда не был системой контроля версий (git rebase и вместо Берии у вас Бернингов пролив), а теперь этот ценный функционал - расширили на всю файловую систему . Это ж просто праздник какой-то ...
А чем он был?
> А чем он был?Хэшед-Блобо-Мэйкером
Неплохой клиент для обмена патчами по электронной почте.
Это он тебе кажется неплохим пока ты не видел того чудовищнейшего костыля, который эти одаренные используют для выковыривания патчей 4 of 125 из этой самой лохотронной почты.Неплохим он был бы в те времена когда tcp.c в линуксе был файликом аж в восемь что-ли килобайт, и любые патчи действительно умещались в экран просто в силу примитивности кода.
Но в тот момент Линус вообще не мог взять в толк чем его /usr/src/linux-новаяпапка110-не-удалять плох.
> Я не понимаю, чем вы недовольны ?? Git никогда не был системой
> контроля версий (git rebase и вместо Берии у вас Бернингов пролив),Вот там бы он навсегда и оставался.
Не мы превратили это в социальную сеть.
Но что не так с git rebase?
А чего плохого в том, что вы можете перезаписать свою локальную историю? Rebase - это отличный инструмент, чтобы навести порядок после активной разработки крупной фичи в ветке. Да и если сам себе историю испортишь - ну так сам и виноват.push --force же обычно все здравомыслящие люди ограничивают.
Админов localhost'а то налетело... Ну давайте, предложите bzr/hg/svn/rsync/tgz так удобные вам что бы хранить свой бесценный Scrips каталог без которого "все что накоплено годами потеряно Нафаня!"
Fossil батенька
Выглядит здорово, но киллерфич из-за которых случилась бы массовая миграция на него не увидел в их табличке "сравнения с git".
Возможно когда-нибудь оно и заменит git, если кто-то крупный начнёт его активно фосить
https://cs8.pikabu.ru/post_img/2018/11/10/9/1541861979172111...И никакой git не нужен. Git для неудачников и неучей
> https://cs8.pikabu.ru/post_img/2018/11/10/9/1541861979172111...
> И никакой git не нужен. Git для неудачников и неучейХранить бинарный формат в git? Дифы как будешь смотреть? Проще уж бэкапить.
https://cs7.pikabu.ru/post_img/2018/06/05/5/1528182161119810...а программисты просто обленились совсем.
Если у тебя винда - освой уже версионирование документов при помощи корзины ... Очень удобно.
Только никого не допускай другого к компу - все почему-то начинают с очистки корзины.
почему никто не хранит свои деловые бумаги и деньги в мусорной корзине ?
> свой бесценный Scrips каталогпотребитель смузей детектед. у людей это ~/bin директория.
в крайнем случае ~/.local/bin (и на винде тоже).
Смузяки себе оставь, мне чего покрепче или просточаю. И не суди по напиткам людей.
> И не суди по напиткам людей.тут есть еще какие-то люди кроме меня ?
Наоборот, нормальный чувак, в венде так все и делают. Нет там никакой ~
> Наоборот, нормальный чувак, в венде так все и делают. Нет там никакой
> ~у меня есть.
впрочем у меня и /bin есть.
Ошибки с использованием символьных ссылок будут вечно встречаться во всех программах. С ними крайне сложно работать
интересно, а тут телеметрию не планируют ввести? /sarcasm
что-то не нашёл кто вносит в разработку git наибольший вклад
В мфц сделали документооборот на свн c бекапами в рар, чтобы на гите не страдать. Не зря.
> В мфц сделали документооборот на свн c бекапами в рар, чтобы на
> гите не страдать. Не зря.seriously? отдает конечно васянством, но в целом я восхищен. То есть даже догадались что в этом случае _distributed_ vcs не то что нахрен не нужна, а просто вредна.
Впрочем, система МФЦ еще год назад было первой (перед Гагариным) вещью которая действительно позволяла считать этустрану не безнадежным аутсайдером абсолютно во всем. Ничего подобного не было, насколько мне известно, ни в одной стране мира (внешне похожее но почему-то-не-работает не в счет). Причем там и технологии, и персонал набранный с нуля и выдрессированый на реальную помощь, а не эти вот совковые тетки васздесьнестояло, и изменения в законодательстве (не говоря уже о внутренних инструкциях и правилах) сделавшие все это возможным.
(Увы, ее стали активно ломать и доламывают уже окончательно. Слишком просто рабам жить стало. Надо усложнять!)