После двух месяцев разработки представлен релиз распределенной системы управления исходными текстами Git 2.51. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63742
Трудно представить большее Легаси.
Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforce
> Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforceЩа я вас всех уделаю. Microsoft TFS (Team Foundation Server). Вот это я понимаю - легаси. VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок просто.
>VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок простоВ это время 1С с их Хранилищем конфигураций: "это почему это - легаси?"
А про Microsoft Visual SourceSafe слыхал? "База" просто расшарена по сети как сетевая папка с доступом на запись всем
С Git так тоже можно. `git clone file:///path/to/repo` и вперёд.
> А про Microsoft Visual SourceSafe слыхал? "База" просто расшарена по сети как
> сетевая папка с доступом на запись всемКраем уха, да. А вон то зачетная штука. Дев в проекте заболел? А вот иди ищи теперь админа, локи с его файлов сбить. Или кукуй без редактирования. Вот это я понимаю, продуктивный девелоп. А уж вещи типа 3-way merge? Черт, про такие навороты индусам MS рассказать забыли.
> Трудно представить большее Легаси.Что-то у тебя анон плохо с фантазией. Bitbaker, perforce, cvs, svn. Hg, наконец.
> Что-то у тебя анон плохо с фантазиейАнон не понимает значения слова "легаси".
>> Что-то у тебя анон плохо с фантазией
> Анон не понимает значения слова "легаси".Все вон то перечисленное - это легаси :D
BitKeeper, Bazaar
hg с гитом ровестники тащемтa
> hg с гитом ровестники тащемтaНо один legacy а другое нет. Так бывает, да. Legacy в софтострое - это по "выпало из употребления". Если вы хотели таксопарк замутить, всюду уже чуть не беспилотные такси, а вам достались брички и лошади - не так уж важно что лошади молодые, брички - новее чем вооооон тот рыдван соседнего таксиста.
Тут другое: одно поделие - никчёмная наколенная поделка Трольвадса "для приёма патчей по мылу", а другое - грамотно спроектированная DVCS.
> грамотно спроектированная DVCSНастолько грамотно, что еле шевелиться на больших проектах. Спасибо, уже плавали.
> Тут другое: одно поделие - никчёмная наколенная поделка Трольвадса "для приёма патчей
> по мылу", а другое - грамотно спроектированная DVCS.Торвальдс знал что надо для девелопа больших проектов, с географически распределенной командой. И сделал - это. Оно просто работает, делает то что ожидается продвинутыми девами и под ногами не мешается, разве что всяким мышевозилам, из которых девелоперы... кхе-кхе.
А "грамотные проектировщики" - накорябали месиво на питоне, делающее мозг. То тормозами, то отсутствием нормальных бранчей, то невозможностью историю немного расчистить в проекте. Зато во, вожжи и оглобли - для покусаных SVN приволокли! На случай если извозчика не попустило и он не понял что в авто "лошадиные силы" - абстракция, а 120 лошадей под капот - вообще никак! Так что и вожжи дергать - незачем.
В конце концов "грамотным проектировщикам" вбили в гроб даже не гвоздь а сразу осиновый кол, столь же грамотные девелоперы питона. Чтоб точно ЭТО не вздумало по кладбищу дефилировать. Они там что-то скрипели - "питоннетормозит", "почти переписали на раст", но к тому моменту команты в основном сводились к "сгинь, нечисть!"
А так - все правильно сделали! Офигенные проектировщики. И управленцы проектом. Если кто хотел посмотреть как проекты делать не надо - отличный пример. Учиться на чужих ошибках лучше чем на своих :)
Сразу видно "не видел, но осуждаю", начитался бреда в интернете, выбрал что подходит под своё уютненькое мировоззреньице и потом это всё накладывает в интернетах.Другое дела когда ешь оба помёта десятилетиями.
А вот нишмагла это именно про гит-ару. Священная вера в Ся не спасла. Поэтому книго-лицые свою бессмысленную моно-репу на жидком и держат(-али).
А жидкий тем временем на ржавый и перекатывается (ядро - уже). Так что вот тебе ещё один повод для хейта.
А так как для большинства репы это помойка изменений, то брюзжание слюной бессмысленно.
А вот что реально жаль - так это штиль в развитии Pijul и Ко.
Аказывается жидкий не использует его механизм слияний, что меня в своё время сильно расстроило.
Хотелось бы посмотреть на скрещенное чудовище Pijul-подобных и Hg-подобных.
Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели компетенции не хватает, или же все жуют жвачку, только лишь потому что - мода такая?
Из наиболее известного − репозиторий плеера qmmp работает на SVN, то есть не все используют git
почему не используют сохранение по папкам с именами версий а хотят вендор-лок SVN ? неужто из за того что мода такая, а?
Я думаю программисты не пользуются SVN потому git удобнее и фичастее, а еще он децентрализованный, а значитт позволяет работать со скаченными исходниками без подключения к Интернету.
Сейчас просто нет бесплатных хостингов с svn, поэтому тупо некуда деваться.
> Сейчас просто нет бесплатных хостингов с svn, поэтому тупо некуда деваться.А нету их потому что SVN и HG хочет пользоваться - полторы необучашки. Спецом для них сервак держать достаточно нерационально получается. Оостальные ЭТО юзать просто не хотят при наличии git. И с hg такая же фигня вышла.
Простите но у git воркфлоу и устройство в целом - логичнее всего для распределенных команд. А если вы не это хотели - нафиг вам DVCS?
И предлагает сотни способов выстрелить себе в ногу. В отличие от всяких там SVN и Hg.
> И предлагает сотни способов выстрелить себе в ногу. В отличие от всяких там SVN и Hg.Вот уж про Hg не надо. Сотни способов бега по граблям - которые стреляют в... в общем не в ногу.
>Почему программисты не пользуются SVNПотому что ушли с этого г-на на GIT и вспоминают этот кошмар как страшный сон.
> Потому что ушли с этого г-на на GIT и вспоминают этот кошмар
> как страшный сон.Удваиваю этого анона. В жизни больше svn использовать не буду. В git можно девелопать как белый человек, хот 100% локально, быстро делать git bisect и что там еще - без постоянной выкачки половины проекта заново, что бывает мучительно тормозно если это не соседний сервак на гигабитной сетке.
Ты, видно, не очень часто работаешь с SVN, не знаешь, что такое ветки мержить в SVN.
Я тебя удивлю, но также, как и в git, через svn merge
А мы это лет наверное 15 назад это делали даже один раз
нифига не так-же
Ну да, не думали про линейность истории и прочие вещи.
и сиди *бись с неразрешимыми конфликтами, появляющимися на ровном месте. нельзя просто взять и держать две svn ветки синхронизированными, проще уволиться
> Я тебя удивлю, но также, как и в git, через svn mergeПроблема в том что это "немного" не так же. И рулить большим проектом где эн людей поредактировали то и се и свести это все воедино... не, господа, гит показал что так работать - нельзя.
> Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели
> компетенции не хватает, или же все жуют жвачку, только лишь потому
> что - мода такая?Я вот юзаю git на вон той репе с лично моим проектом - локально. Во я себя заведорлочил то. А в чем бенефит? А вот мне не надо ставить какие там сервера в обязаловку. Я пожалуй не против такого "вендорлока". Сам же и буду как единоличный вендор решать сколько живет моя приблуда.
В качестве точки обмена в вебе опять же несложно гит нарулить. И в отличие от svn все копии репы равнопрравны и могут прекрасно наигировать по всей истории без того сервера. А в SVN на большом проекте нечто типа git bisect вообще задолбаешься нахрен делать, когда оно половину интернета выкачивает на каждую ревизию заново.
>лично моим проектом - локальноЯ тебя может удивлю, но svn давно умеет работать локально. Просто репу придётся держать в отдельной папочке.
>>лично моим проектом - локально
> Я тебя может удивлю, но svn давно умеет работать локально. Просто репу
> придётся держать в отдельной папочке.Я тебя удивлю, но в git изначально все репы - равноправные и со всей историей. И полной функциональностью. Это - то как я хочу видеть работу с исходниками при активном девелопе на самом деле.
А через какой реп convergence и обмен - лишь вопрос договоренностей участников проекта. Договоримся через меня - будет через меня. Договоримся через Васю, будет через Васю. Это буквально 1-2 строки конфига подрихтовать для смены дефолтов. Более того, я могу "вот эту операцию" сделать - "с вон той ремотой", _разово_, если мне это надо. Ну и где этот ваш свин по сравнению с этим всем? Он - не про это вообще. Недоразумение для полутора корпоратов с централизованынм workflow и убер-серверами.
Потому что:
1) "мы тоже хотим быть как боги". Ну, то есть как разработчики ядра;
2) гитхаб сделал git доступным для каждой домохозяйкиНо всё же другие системы управления исходниками гораздо более для людей, главное не сужать свой кругозор до SVN.
> Но всё же другие системы управления исходниками гораздо более для людей,Не стоит путать ящеров, домохозяек и домохозяек-ящеров с людьми.
> вендор-локом GITи как он вендор-лочит? Вот я установил себе гит на комп, создал с его помощью репу. Я на кого завендорлочился?
> и как он вендор-лочит?Боюсь, ответа от него мы не увидим: очевидно же, что это был наброс на вентилятор.
На компьютер)))
Смешно! Да сейчас жить без майкрософтного гитхаба невозможно, таким образом, GIT завендорлочен майкрософтом. А всякие мелкие git хостинги - посмешище, ими никто не пользуется!
> Да сейчас жить без майкрософтного гитхаба невозможно, таким образом, GIT завендорлочен майкрософтом.О чем ты? Git вообще не требует никакого "хостинга", ибо является распределенной системой.
В коммерческой разработке вообще плевать хотели на все эти гитхабы и иже с ними: у ребят свои серваки с "эталонной" репой. А он про вендорлок...
Очевидно, уважаемый любитель SVN к разработке не имеет никакого отношения.
Да ты не понимаешь! Это понятно, что GIT - распределённая система, однако речь то про опенсорс! А вот майрософт подмяла под себя опенсорс выкупив гитхаб и npm, вот так вот! Поэтому, весь опенсорс завендорлочен на гитхаб!
> Поэтому, весь опенсорс завендорлочен на гитхаб!Это бред какой-то. Далеко не весь опенсорс на Гитхабе, поэтому никакого вендорлока нет.
потому что svn merge это орудие пыток, а не разработки
в каком месте там вендор лок?на каком конкретно вендоре ты залочен?
То что git написан в основном на C90 показывает какой git капролит
Единственный нормальный комментарий во всей ветке.
4 ошибки в одной строке текста опровергают Вашу гипотезу.
Расскажите, что написано не на Си или не использует либы написанные не на Си, и при этом не копролит? Будем вместе с вами переходить не на копролит.
Квалификация позволяет.
jujitsu (https://github.com/jj-vcs/jj)
Дело не в Си, а в C90. Ещё бы на ANSI C писали бы, когда в ходу C17 или хотябы C11
C90 это и есть ansi c (c89), только его международная (iso) версия. Там правок между ними, кот наплакал!;)
> То что git написан в основном на C90 показывает какой git капролитА то что ты даже "копролит" правильно написать не можешь - показывает уровень. Это от слова copr - как там его федора расшифровывает. Шутка, но в каждой шутке... :)
За шо хэйт?
>отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256А протокол передачи на remote и поддержку в forge-ах они реализовали? Или предлагают перейти на воркфлоу с патчами, как в ядре linux?
> А протокол передачи на remote и поддержку в forge-ах они реализовали? Или
> предлагают перейти на воркфлоу с патчами, как в ядре linux?Куды эти форжи денутся? Запилят как зайчики.
Да, гит будут пилить вместо авторов гита. Не, просто дистры перестанут обновлять гит.
У меня это какой-то лютый когнитивный диссонанс вызываетС одной стороны это backbone всей it индустрии и я этим отличным инструментом пользуюсь каждый день на 110%.
С другой стороны в этой версии разрешили использовать стандарт которому не 35 лет, а всего 25(!) и то только частично
Буквально пару версий назад писали что наконец-то git по окончании своей работы не тупо забивает на очистку памяти а правильно освобождает память как положено. И мол именно это блочило git от того чтобы завернуть его в dll и поставлять в таком виде всяким приложениям с gui потому что если консольное приложение в конце теч`т, то как бы пофиг, но для dll это проблема.
Как так вышло что то что является фундаментом качественного кода и принципиально важной вещью, для разработчиков git всего лишь несущественная рекомендация которую начали соблюдать только потому что есть план заворачивать это все в dll ¯\_(ツ)_/¯
Читать git release notes - это для смелых духом
> И мол именно это блочило git от того чтобы завернуть его в dll и поставлять в таком виде всяким приложениям с guilibgit2 же всегда для этого был.
Я ссылаюсь на вот эту публикацию:
https://github.blog/open-source/git/highlights-from-git-2-48...
Очевидно главное целеполагание.Гит должен работать на всех доступных системах.
Вот и будет работать на системах 25-летней давности.
А по поводу освобождения памяти.
В Си для простых структур делать его легко - для сложных - тяжко.
Сначала заморачивались на функциональность. И никто не мешает вызывать утилиты с нужными опциями из своих программ. Линус так вообще шареные библиотеки недолюбливает. Но это его личные тараканы.
я как-то очень смутно себе представляю работающую систему которой 25 лет и в которой реально что-то разрабатывают на git. Думаю количество таких кейсов исчезающе мало и место им или в музее или на ретро выставке. А даже если таких кейсов в мире больше 1к, не вижу причин почему бы им не посидеть на более старых версиях git, если есть такая необходимость.Потому не вижу обоснованных причин, почему git должен учитывать такие кейсы при разработке
> я как-то очень смутно себе представляю работающую систему которой 25 лет и
> в которой реально что-то разрабатывают на git.Linux Kernel не подойдет? Правда чем его юзкейсы такие особенные - хз.
> Потому не вижу обоснованных причин, почему git должен учитывать такие кейсы при разработкеКак зрячий может объяснить слепому от рождения цвет заката?
Как портируете git на абак, можем продолжить разговор
Если нельзя разглядеть монету на расстоянии пяти километров то зачем зрение?
Господи, что ты несешь? 🤦
А чего ты на абак так не агришься?
А почему тебя это волнует? Может, мне твоё выступление больше нравиться. 😉
> Как зрячий может объяснить слепому от рождения цвет заката?Осознать как работает зрение. Запилить нейроинтерфейсы. Прицепить камеры. Доразвить технологии. Показать. В этом мире очень мало чего принципиально невозможного.
> Осознать как работает зрение. Запилить нейроинтерфейсы. Прицепить камеры. Доразвить технологии. Показать. В этом мире очень мало чего принципиально невозможногоЕсли не считать того, что для зрения нужен мозг. А если он в детстве не настроился на хорошее зрение. То во взрослом возрасте хорошего зрения уже не будет, что бы ты с глазами не делал.
Можно, конечно и мозг заменить - но это уже совсем другая история.
> Гит должен работать на всех доступных системах.Вообще-то речь не о работе, а о его компиляции ущербными компиляторами.
какие .dll ...винда для Git это инородная среда.
Git в винде, как криво-портированная приставочная игра и он до сих пор себя так ведёт, например очень долго клонирует, то что в Linux за секунду клонируется и портит файлы, добавляя неправильные CRLF к строкам.Более-менее нормально Git в винде можно использовать только в WSL и желательно не на NTFS
Когда в обновлениях говорится об улучшениях производительность, думаю по-умолчанию понятно, что речь не о винде. В винде он как работал криво так и будет. В отношении винды подход разработчиков Git больше: "Скажите спасибо, что он вообще там работает". Даже если бы не было версии Git для Windows, это не значит что не нашлось бы другого способа его использовать, как тот же Ansible - для винды его нет официально, но это не мешает его гонять в винде.
> Более-менее нормально Git в винде можно использовать только в WSL и желательно
> не на NTFSА ты думал что WSL майкрософт от хорошей жизни сделал? Не, просто свои средства девелопа у майкрософт настолько ужасны что в винде вместо девелоперс остались - велоперы какие-то. Остальные из винды сделали драп-драп-драп.
И тут майкрософт начал догадываться что таким макаром их экосистеме скоро будет амба. Совсем. Невосстановимая. Потому что без девелоперс девелоперс-экосистемы - бай-бай. А экспериентс для девелоперс у майкрософт - ну вот такой вот.
И да, у NTFS самого по себе перфоманс - голимый. С git на линухе народ просто ворочает проекты и размером не парится. И тут юзер винды с нтфс, отставая на 2 квартала, пыхтит высунув язык...
>Компилятор с поддержкой C99 является обязательным для Git c 2021 года, но возможности спецификации C99 внедряются крайне осторожно для сохранения совместимости с компиляторами, лишь частично поддерживающими данный стандарт.Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор лишь частично реализовали его поддержку.
Может уже и не реализуют никогда? Может там bus factor?
> Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор лишь частично реализовали его поддержку.В старых системах компиляторы старые. А git должен работать везде.
И за такой подход его надо в качестве учебника использовать.
Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.
> git должен работать везде.Ну пусть старые системы и сидят на старой версии git - он у них будет работать
Что-то мне подсказывает что если ребята не обновляют оборудование по 25 лет, то и свежий git им погоды не сделает> Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.
Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере
> если ребята не обновляют оборудование по 25 летС чего вы так решили? ОС и оборудование - несколько разные вещи.
> Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере
Можно и не так. Только тогда надо смирится с минусами, вытекающими из-за отказа от "такой манеры".
> Только тогда надо смирится с минусами, вытекающими из-за отказа от "такой манеры".Какими, например?
> Какими, например?Всплывающими проблемами.
Какими проблемами?
Всплывающими.
Понятно.
> Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.Нормальные программисты не пользуются ущербными компиляторами языков из 70х под дохлые системы, если только этого только прямо не требует задача.
> Нормальные программисты не пользуются ущербными компиляторами языков из 70х под дохлые системы, если только этого только прямо не требует задача.То есть разработчики git - ненормальные?
Разработчики git не могут использовать последние фичи С потому что их не поддерживают неполноценные компиляторы типа msvc. А вовсе не потому, что у них была цель поддерживать старые системы (или компиляторы), как ты о том наплел.И, кстати, да - это последствие выбора убогого языка из 70х. Выбери они хотя бы C++ - и проблемы с msvc не было бы, ибо с его поддержкой у msvc все отлично.
🤔 Ну кстати технически они все еще могут
с++ будет для них максимально простой миграцией среди всех остальных языков
Плюс компиляторы для с/с++ почти всегда одни и те же
> И, кстати, да - это последствие выбора убогого языка из 70х. Выбери они хотя бы C++ - и проблемы с msvc не было бы, ибо с его поддержкой у msvc все отлично.То есть убогий язык MS не смогла реализовать а C++ смогла?
Кто мешает собирать для MS другими компиляторами?
И это из кодинг стандарта:Shorthand like ".a.b = *c" in struct initializations is known to trip up an older IBM XLC version, use ".a = { .b = *c }" instead. See the 33665d98 (reftable: make assignments portable to AIX xlc v12.01, 2022-03-28).
А кто автор и духовный лидер Git? Ни разу его чего то не упоминали.