Опубликован выпуск распределенной системы управления исходными текстами Git 2.48. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62545
> Предполагается, что удаление устаревшей функциональности произойдёт в выпуске Git 3.0, в который войдут изменения, нарушающие обратную совместимость.Должно быть только так и никак иначе. А то куда ни гляну. В минорных релизах ломают совместимость с обоснованием "оно уже год депрекейтед" (ну или 3 года, совершенно неважно).
Так эта.. "живи быстро, умри молодым"… Тьфу, не оно! "Обновляйся быстрее, живи свежО". Вот и ломают :)
Не только лишь все научились соблюдать semver, увы.
>"оно уже год депрекейтед" (ну или 3 года, совершенно неважно).Точно. Вот и в ядре выпиливать устарешие архитектуры и устаревшие(?) файловые системы следовало бы в 7.0
Кому должно? Смотри, я разрабатываю библиотеку. Допустим, выкидываю поддержку какого-нибудь древнючего питона 3.8. Нет чёткого определения breaking это change или нет, поэтому я могу бампнуть мажорную версию или не бампнуть по своему усмотрению. Если я не бампну, я сломаю пользователей питона 3.8. Если бампну, значит вообще всем моим пользователям придётся для обновления прикладывать дополнительные усилия, как-то обновлять вервию в pyproject.toml, читать changelog на тему того что могло сломаться и покрыто ли оно их тестами и гонять эти самые тесты.У меня лично выбор между всеми пользователями и кучкой некрофилов даже не стоит. Совместимость с python 3.8 будет не просто сломана когда-нибудь, она будет сломана намеренно на следующий день после его EoL, разумеется с бампом только patch версии, чтобы неповадно было.
Лучший?
порог входа слишком высок, ни один веб-сеньор ещё не побежал сломя макбук переписывать на раст
UPD: а хотя уже побежалиhttps://github.com/GitoxideLabs/gitoxide
9K звёзд, 14K коммитов и 1940 релизов (тысяча девятьсот сорок). но пока что только клонировать умеет, и то не всё
Если почитать внимательнее, то умеет он сильно больше, чем клонировать. Он же не с командлайновой тузлы начал, а с реализации всех внутренних механик гита в виде библиотеки. Когда все библиотеки будут закончены (а они закончены почти все), тогда, используя их будет и полноценная CLI.Я за ними уже года три слежу, что бы свой гитовый сервер запилить, влезающий на дохлую виртуалку.
Можно уже использовать gotwebd/gotd для дохлой виртуалки.
> gotd does not yet support version 2 of the Git network protocol.Оксайд-то как раз вторую делает.
> Можно уже использовать gotwebd/gotd для дохлой виртуалки.Для дохлой виртуалки можно и cgit так то. Даже если ее совсем вынесут - там все равно кроме этого гита брать нечего. А попытки комитов ессно будут светиться на радаре как ошпаренные. И ради чего все это жданье, спрашивается?
> Я за ними уже года три слежу, что бы свой гитовый сервер запилить, влезающий на дохлую виртуалку.я не ждал тжри года, пока что-то доделают на расте, взял cgit на сишечке и пользуюсь
> Если почитать внимательнее, то умеет он сильно больше
ложь. если почитать внимательнее, то он не умеет даже клонировать
> ложь. если почитать внимательнее, то он не умеет даже клонироватьбгг. типичная растоперепискивательная история. Мы придумали гениальную библиотеку, которая будет уметь всьо. Но...ой... пока она существует только в наших фантазиях.
> я не ждал тжри года, пока что-то доделают на расте, взял cgit на сишечке и пользуюсьcgit, как и все подобные "простые" решения, не умеет Git 2.
cgit это вообще-то веб-морда. работать с git на своём серваке можно как угодно
Предлагаю почитать описание cgit и его фич на официальном сайте. Для ленивых:> cloneable URLs (implements dumb HTTP transport)
Это значит, что современный транспорт Git 2 он не поддерживает, и полагается на мегадревнюю и тупую реализацию транспорта, с которой у разного софта проблемы, потому что никто этим давно уже не пользуется и не тестирует.
> работать с git на своём серваке можно как угодноне только через http transport от cgit
> ложь. если почитать внимательнее, то он не умеет даже клонироватьhttps://github.com/GitoxideLabs/gitoxide/blob/main/crate-sta...
Вы о чём вообще говорите-то? Я например про проект gitoxide. А вы, похоже, про командлайновую тулзу для конечных пользователей.
В проекте gitoxide огромное количество сделанной работы, отображённой галочками в этом документе под каждой библиотекой. Конечная тулза делается на основе библиотек, а не наоборот.
> Вы о чём вообще говорите-то?читай галочки в ридми
Чел, ты угораешь что ли? Смотри на реализацию фич библиотек. Это то, что реализует все внутренние механики гита. Огромное их количество реализовано. Ты же смотришь на командлайновую тулзу для пользователей, в которой мало что есть, потому что библы ещё все не закончены.Этот проект на гитхабе - это не командлайновая тулза. Это прежде всего набор библиотек который реализует всё, что есть в гите, на основе которых потом можно делать что угодно: командлайн, гуц, встраивать в сервера, и тд.
> 9K звёзд, 14K коммитов и 1940 релизов (тысяча девятьсот сорок).
> но пока что только клонировать умеет, и то не всёКажется они поняли release early, release often весьма буквально. Интересно, а релизы им роботы нарезают, без чанжлога даже? Тогда пусть и пользуются тоже - роботы ;)
А как же https://github.com/facebook/sapling
А как типичная поделках хрустиков (ну или как типичный опенсорс от мордокниги, что, впрочем, одно и то же).https://github.com/facebook/sapling/blob/main/eden/mononoke/... - даже не компилируется. Но нате на лопате непонятные бинарники with key areas omitted are:
Documentation on how to configure.Зато cli - прям замечательный. Зачем нужен - не признаются.
И в таком вот виде - "даже и не компилируется" оно пребывает уже лет ДЕСЯТЬ.
Отдельно смешно что изначально заявлялось как замена _hg_, а теперь, гляньте-ка - ни одного упоминания hg в ридмишечке, "Git-compatible source control system", ага. (дайте угадаю - вы не найдете в логах того места где оно вдруг стало из hg гитом. Ну а память у хрустоистеричек - девичья.)
Я боюсь открывать мордокнижкин прожект по переписькиванию пехепе - кто смелый, возьмите длинную палочку и гляньте - а то вдруг там уже s/php/1c/ (и forced push, чтоб замести следы)
Они назвали свой язык Hack, и он уже довольно существенно отличается от PHP. Как drop-in замена PHP уже давно не позиционируется.
...и, вообще говоря, выглядит их язык куда лучше, чем нынешний PHP.Если в PHP 8.4 добавлены исключительно синтаксический сахар, то в Hack добавлены дженерики, async-await и подобные реально нужные вещи.
ну вот свою версию меркуриала они назвали соплинг или как-то так - а теперь вон васян с памятью рыбки гуппи внезапно обнаружил что это гит и "всегда был".Так что ты зайди, и глянь, осторожненько, широко окно не открывай. Может там уже "существенных отличий" от 1C зато не осталось. (но по прежнему нельзя скомпилировать, конечно же - тоже уже лет десять, наверное)
Они это всё делают для своих внутренних целей, в опенсорс выкладывают скорее для привлечения новых сотрудников - пилить язык программирования или систему контроля версий всяко интереснее, чем формы шлёпать. На их CI компилируется - им этого достаточно.Трогать это, не будучи сотрудником Meta и не планируя устроиться туда на работу, довольно бессмысленно.
> Они это всё делают для своих внутренних целей,для меня полнейшая загадка зачем они это делают и кого этим надеются завлечь.
> Трогать это, не будучи сотрудником Meta и не планируя устроиться туда на
> работу, довольно бессмысленно.Как будто даже планируя - ты устроишься именно переписывателем на хрусте. (напомню что весь php на сегодня - это два человека, весь git - человек пять, вроде, еще остались - так что в фейсбуке эта должность тоже уже давно занята, там по полтора на каждую)
Каким сумасшедшим по уши в кредитах надо быть чтоб пойти к ним работать - даже и представить себе сложно.
> Отдельно смешно что изначально заявлялось как замена _hg_, а теперь,
> гляньте-ка - ни одного упоминания hg в ридмишечке, "Git-compatible
> source control system", ага. (дайте угадаю - вы не найдете в логах
> того места где оно вдруг стало из hg гитом. Ну а память у
> хрустоистеричек - девичья.)Баззворд иссяк. Видимо всех необучашек уволили или перевели на гит - проблема и отпала. А HG к тому моменту как раз бесславно сдох по причине "версия питона не та". Скучать о куске тормозного питона от тех кто пытался DVCSом SVN комплетить - очень мало кто будет.
Когда там гит появился? Году в 2004? Выросло поколение, для которого "git был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы "другого" они и не видели, так что чоужтам...
> Когда там гит появился? Году в 2004? Выросло поколение, для которого "git
> был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы
> "другого" они и не видели, так что чоужтам...Я немного пользовался CVS и SVN - но это тот случай когда я с удовольствием забуду всю эту дрянь повернутую на единственном огромном центральном сервере - как страшный сон.
Еще были всякие проприератщики типа Bitbaker. Они делом показали почему с проприетарщиками не следует иметь дел в своих воркфлоу. Торвальдс делом покахал как оборзение проприетарщиков лечить правильно. И многие из нас усвоили этот урок. Never again.
>> Когда там гит появился? Году в 2004? Выросло поколение, для которого "git
>> был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы
>> "другого" они и не видели, так что чоужтам...но врать научились прям сразу как рот открывают.
> Я немного пользовался CVS и SVN - но это тот случай когда
> я с удовольствием забуду всю эту дрянь повернутую на единственном огромном
> центральном сервере - как страшный сон.т.е. ты ничего и не помнил.
"единственный", "огромный", ага.
Очередная чушь собачья от эксперта ни в чем.
>> Я немного пользовался CVS и SVN - но это тот случай когда
>> я с удовольствием забуду всю эту дрянь повернутую на единственном огромном
>> центральном сервере - как страшный сон.
> т.е. ты ничего и не помнил.Я в те античные времена немного возился с реактосом - и помню какая это боль была! И с CVS, и с SVN. Они изначально IIRC cvs юзали, потом на svn перешли. Толку - мизер, на мой вкус и то и другое - сорта д@рьма.
Главная моя проблема? Эта дрянь истошно тормозила. Всегда. Везде. Все операции с версиями.
- Апдейт проекта? Половину сервака перекачивает.
- Отмотать версию? Половину сервака перекачивает.И все это при неумении в дельты как я понимаю - так что если это не гигибатный линк в локалке - это боль. Зачем мне инструмент который свою заявляемую функцию делает как УГ?
И нет, если я хотел запилить свой проект, это не означает что я хотел сетапить серваки, косплеить DBA или что там. Я хотел - проект сделать. А этот крап - отодвигает меня от занятий вот этим - в занятия ненужным мне хзчем. И тиму админов ты мне явно не оплатишь, да?
Прикинь, я занимаюсь программизмом - по жизни. А не "40 часов в неделю". Мне это нравится. И я буду юзать тулы - которые поддерживат мои начинания.
> "единственный", "огромный", ага.
> Очередная чушь собачья от эксперта ни в чем.Да не бойся ты так: взаимодействовать в этих твоих CVS и SVN я с тобой все равно не буду, со своей стороны видал я такие взаимодействия и их адептов - понятно где. Вон тебе user, вы нашли друг друга. Профи перехода на виндочку и демонстрации импотенции ваших принципов. В этом вы - такие одинаковые. Это ваш уровень :)
>> Когда там гит появился? Году в 2004? Выросло поколение, для которого "git
>> был ВСЕГДА" и ничего не то, чтобы "лучше", а хотя бы
>> "другого" они и не видели, так что чоужтам...
> Я немного пользовался CVS и SVN - но это тот случай когда
> я с удовольствием забуду всю эту дрянь повернутую на единственном огромном
> центральном сервере - как страшный сон.
> Еще были всякие проприератщики типа Bitbaker. Они делом показали почему с проприетарщиками
> не следует иметь дел в своих воркфлоу. Торвальдс делом покахал как
> оборзение проприетарщиков лечить правильно. И многие из нас усвоили этот урок.
> Never again.Ну, если пользовался так же, как и git'ом - "по оглавлению", то я и не удивлён, чо. Сильно менее удобно, ясно-понятно.
> Ну, если пользовался так же, как и git'ом - "по оглавлению", тода, умение автоматически встроить содержимое readme.md в веб-версию корневого каталожка проекта - это безусловно достижение. Правда, не гита, а гитхапа и гитляпа.
Но наш специалист ни в чем вряд ли разбирается в этих тонкостях. У него "оглавление".
> Но наш специалист ни в чем вряд ли разбирается в этих тонкостях.
> У него "оглавление".Специалист ожидает - что инструмент который сватается как система контроля версий будет "do it well". А мой опыт с CVS и SVN - хтонически отвратительный. Они вообще почти не VCS, так, качалки файлов на стероидах. Хтонически неэффективные и тормозные, если это вдруг не гигабитный интернет в той же локалке. Корпоративным наймитам похрен, а вот всем остальным...
> Ну, если пользовался так же, как и git'ом - "по оглавлению", то
> я и не удивлён, чо. Сильно менее удобно, ясно-понятно.Меня там для начала дико бесил - перфоманс перематывания версий. С какого-нибудь реактоса другую версию переключить, на каком-нибудь ADSL линке - о, это такая весьма отдельная боль. И туповйэтинг полчаса. Когда я уже вообще забыл нахрен - а что я вообще хотел.
Очень эффективные тулсы для взаимодействия с географически распределенной тимой, аж 2 раза. Git к этому - гораздо ближе. А что вы там 40 часов в неделю кодите в своих конторах с вашими "якобы супер" тулсами мне вообще - не интересно. Я уже насмотрелся на таких же с TFSом. Еще один сорт такого же по смыслу д@рьма. Вечно тормозит и делает мозг, вместо контроля версий.
А на гит все это норм работает. Я даже линухкернел по GPRS пару раз апдейтил. Главное это инкрементально делать, чтоб дельта не накапливалась. И тупняк - где-то там, разово. А в остальном перфоманс операций с версиями - ломовой. Что мне и надо от VCS.
А для лично себя и своих проектов - в гробу я видал серваки и бд сетапить чтобы свой проект версионировать. ИМХО git был epic win'ом. Намного ближе к тому что я хотел.
>> Ну, если пользовался так же, как и git'ом - "по оглавлению", то
>> я и не удивлён, чо. Сильно менее удобно, ясно-понятно.
> А для лично себя и своих проектов - в гробу я видал
> серваки и бд сетапить чтобы свой проект версионировать. ИМХО git был
> epic win'ом. Намного ближе к тому что я хотел.И где ж ты, "пользовавшийся" CVS и SVN в них "бд"-то нашел, а? Подскажи пенсионеру - совсем склероз замучал...
> И где ж ты, "пользовавшийся" CVS и SVN в них "бд"-то нашел,
> а? Подскажи пенсионеру - совсем склероз замучал...По моему какие-то версии свина - пытались тянуть какие-то db-тулсы? Но лично меня больше всего анноило - что ему для любой операции с вон той репо - надо вечно качать полсервака по сети, и даже без дельта компресии. А перфоманс операций - ужасен.
Как вы поняли - это вовсе не добавило энтузиазма в освоении этих каках. И всерьез я учился с VCS работать, like a boss, уже и правда на git. Который всем этим - не страдал. Так что я немедленно прикрутил его к своим проектам, взял быка за рога - и вот так - все намного эффективнее осваивается.
Поймите меня правильно. Я SVN последний раз видел и юзал - лет 10..15 назад. Это было настолько давно - что я уже даже не знаю сколько лет назад. Так что да, я могу и прогнать в этой таксономии динозавров. Это никогда не было моим любимым топиком.
Как же из тебя прет ободание и преклонение перед Торвальдсом. Ещё и урок там какой-то усвоил. Блин, какой же ты блаженный. Что ты там усвоил? Ты ж нифига не сделал, это все линус.
Ну тем кому порог входа в git слишком высок лучше чем-нибудь другим заняться.
>В GitHub сборка с упрощённым SHA-1 позволила на 10-13% повысить производительность операций извлечения и клонирования данных.Ждём атак против гитхаба с подменой объектов в репозиториях. Напр. лучше всего подменять picklы.
Да-да, подмены объектов в репозиториях через read-only запросы. Мамкин безопасник.
А есть простая альтернатива для мини-проектов? Чисто отслеживать изменения без всех вот этих "свистелок"?
Mercurial (HG).
Только осторожно, после него вы от гита будете плеваться.
Есть травоядные. Есть плотоядные.А есть те кто hg вспоминает. Они любители особого вкуса.
можно просто не пользоваться функционалом, который не нужендля 90% репозиториев хватает commit, branch, checkout и merge, и ещё push/pull для работы с удаленными серверами
для оставшихся 10% уже нужны остальные 95% гита
добрый старый (разрабатываемый и обновлояемый) svn ?
Git итак простой. Сделал ветку, закомитил изменения в ветку, замержил ветку в мастер когда готово, и так для каждого изменения.
> Git итак простой. Сделал ветку, закомитил изменения в ветку, замержил ветку в
> мастер когда готово, и так для каждого изменения.А почему тогда у вас в конторе, уважаемый Yandex Man, сделали свою систему контроля версий?
Своя система контроля версий сделана из git и имеет совместимый с ним cli (а какой же ещё?). Сделана она потому что у нас мегарепа, настолько большая что на локальную машину её не то что склонировать, но даже просто зачекаутить долго и тяжело. Поэтому там виртуальная файловая система с удалённым доступом к git хранилищу.
А зачем вам, если не секрет, мегарепа? Побить на части не получается?
Это только так кажется. Как только потребуется сделать что-то нестандартное, придётся перелопатить гору манов. Или довериться чатгпт. В такие моменты думаю -- уж лучше бы хранил версии просто в папках. Это будет то же самое, что гит, только без мозгопарева гита с его протёкшими абстракциями.
В целом устройство не такое сложное https://www.opennet.me/opennews/art.shtml?num=52355> Как только потребуется сделать что-то нестандартное
Например?
> Например?Из недавнего:
1) перенести несколько коммитов в другую ветку (случайно не в той ветке сделал)
2) скопировать несколько файлов из старого коммитаДелать это приходилось через какие-то дичайшие костыли.
1. чери пик2. чери пик
убираешь лишнее и
аменд
2. скорее checkout, только не ветки а файловgit checkout commithash pathname
> 1. чери пикКак бы не так. Эти коммиты потом останутся в старой ветке.
И я всё-таки не вижу смысла делать пользование системой контроля версий сложнее чем файловым менеджером. Разве система контроля версий не должна упрощать жизнь, а не усложнять? Для меня понятие "учить гит" само по себе звучит как дикость.
jj установи да
> А есть простая альтернатива для мини-проектов? Чисто отслеживать изменения без всех вот
> этих "свистелок"?Fossil можешь попробовать, но без свистелок - понятие относительное. Там всякие вики и проч - но при этом он довольно мелкий.
Впрочем в сабже никто не заставляет же вон то юзать. Реально вам потребуется 5-10 типовых команд. Остальное это продвинутости и навороты для гуру, то что вы на этот уровень выйдете - еще не факт. А умение git - ценный актив. Это почти везде сейчас - требуется. Зайдите на любой сайт вакансий, прочитайте требования. Отточить этот скилл на именно своих проектах - весьма валидная идея.
> А есть простая альтернатива для мини-проектов?Если вы считаете, что git -- это "сложно" или "не обязательно", у меня для вас плохие новости:
- во-первых это не сложно, чтобы начать с технологией работать, достаточно потратить полдня на чтение маленькой книжки
- во-вторых это фактический стандарт индустрии, и осваивать его всё равно придётся
Что такое `мини-проект`? Если он выкладывается в паблик с тем чтобы им пользовались другие люди, альтернатив нет, потому что никто не будет ставить уродцев типа фоссилов или пихулей чтобы скачать или законтрибутить в твою поделку. А если проект чисто в стол, делай что хочешь.