После двух месяцев разработки представлен релиз распределенной системы управления исходными текстами 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 в софтострое - это по "выпало из употребления". Если вы хотели таксопарк замутить, всюду уже чуть не беспилотные такси, а вам достались брички и лошади - не так уж важно что лошади молодые, брички - новее чем вооооон тот рыдван соседнего таксиста.
https://loshadi-na-prazdnik.ru/
Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели компетенции не хватает, или же все жуют жвачку, только лишь потому что - мода такая?
Из наиболее известного − репозиторий плеера qmmp работает на SVN, то есть не все используют git
почему не используют сохранение по папкам с именами версий а хотят вендор-лок SVN ? неужто из за того что мода такая, а?
Я думаю программисты не пользуются SVN потому git удобнее и фичастее, а еще он децентрализованный, а значитт позволяет работать со скаченными исходниками без подключения к Интернету.
>Почему программисты не пользуются SVNПотому что ушли с этого г-на на GIT и вспоминают этот кошмар как страшный сон.
> Потому что ушли с этого г-на на GIT и вспоминают этот кошмар
> как страшный сон.Удваиваю этого анона. В жизни больше svn использовать не буду. В git можно девелопать как белый человек, хот 100% локально, быстро делать git bisect и что там еще - без постоянной выкачки половины проекта заново, что бывает мучительно тормозно если это не соседний сервак на гигабитной сетке.
Ты, видно, не очень часто работаешь с SVN, не знаешь, что такое ветки мержить в SVN.
> Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели
> компетенции не хватает, или же все жуют жвачку, только лишь потому
> что - мода такая?Я вот юзаю git на вон той репе с лично моим проектом - локально. Во я себя заведорлочил то. А в чем бенефит? А вот мне не надо ставить какие там сервера в обязаловку. Я пожалуй не против такого "вендорлока". Сам же и буду как единоличный вендор решать сколько живет моя приблуда.
В качестве точки обмена в вебе опять же несложно гит нарулить. И в отличие от svn все копии репы равнопрравны и могут прекрасно наигировать по всей истории без того сервера. А в SVN на большом проекте нечто типа git bisect вообще задолбаешься нахрен делать, когда оно половину интернета выкачивает на каждую ревизию заново.
Потому что:
1) "мы тоже хотим быть как боги". Ну, то есть как разработчики ядра;
2) гитхаб сделал git доступным для каждой домохозяйкиНо всё же другие системы управления исходниками гораздо более для людей, главное не сужать свой кругозор до SVN.
> Но всё же другие системы управления исходниками гораздо более для людей,Не стоит путать ящеров, домохозяек и домохозяек-ящеров с людьми.
> вендор-локом GITи как он вендор-лочит? Вот я установил себе гит на комп, создал с его помощью репу. Я на кого завендорлочился?
> и как он вендор-лочит?Боюсь, ответа от него мы не увидим: очевидно же, что это был наброс на вентилятор.
То что git написан в основном на C90 показывает какой git капролит
Единственный нормальный комментарий во всей ветке.
4 ошибки в одной строке текста опровергают Вашу гипотезу.
Расскажите, что написано не на Си или не использует либы написанные не на Си, и при этом не копролит? Будем вместе с вами переходить не на копролит.
Квалификация позволяет.
jujitsu (https://github.com/jj-vcs/jj)
Дело не в Си, а в C90. Ещё бы на ANSI C писали бы, когда в ходу C17 или хотябы C11
> То что 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 должен учитывать такие кейсы при разработкеКак зрячий может объяснить слепому от рождения цвет заката?
>Компилятор с поддержкой C99 является обязательным для Git c 2021 года, но возможности спецификации C99 внедряются крайне осторожно для сохранения совместимости с компиляторами, лишь частично поддерживающими данный стандарт.Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор лишь частично реализовали его поддержку.
Может уже и не реализуют никогда? Может там bus factor?
> Шёл 27-й год со времени принятия C99... А некоторые компиляторы до сих пор лишь частично реализовали его поддержку.В старых системах компиляторы старые. А git должен работать везде.
И за такой подход его надо в качестве учебника использовать.
Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.
> git должен работать везде.Ну пусть старые системы и сидят на старой версии git - он у них будет работать
Что-то мне подсказывает что если ребята не обновляют оборудование по 25 лет, то и свежий git им погоды не сделает> Что бы кандидаты в нормальные программисты учились как надо большие проекты разрабатывать.
Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере
> если ребята не обновляют оборудование по 25 летС чего вы так решили? ОС и оборудование - несколько разные вещи.
> Думаю это сверхобобщение. Далеко не все большие проекты должны брать пример с git и разрабатываться в такой манере
Можно и не так. Только тогда надо смирится с минусами, вытекающими из-за отказа от "такой манеры".