После трёх месяцев разработки опубликован выпуск распределенной системы управления исходными текстами Git 2.40. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58790
чем оно лучше меркуриал?
тем что не сдохло, тем что несмотря на непрозрачность и неудобство CLI - это самое популярное решение, и решает поставленную задачу вполне сносно, тем что вокруг него много серверных и клиентских обверток в том числе онпремиз от бесплатных до космоса, тем что это основная система контроля версий ядра линукса и оно применяется в самых жестких сценарияха хг не может дать ничего, притом не имея ничего из вышеперечисленного
зато хг или тот же свн могут просто работать без ненужных переусложнений, вызванных самой необходимостью имитировать бурную деятельность по разработке не самого сложного по задумке своей инструмента
А ты их хоть одну видел? Просто базовый набор команд (а дальше ты всё равно не смог разобраться) очень похож, буковки только разные)))
Главное захейтить гит, а уж чем это к делу не относится.
я не хейтю, а пишу про его объективный овер-инжиниринг
Что там переусложнено? 3 базовых понятия, 5 команд для работы.
Hg, наверное, да, может просто работать. Но SVN - не децентрализованный. Недецентрализованные уже давно не торт.
Без ненужных переусложнений есть же Got (Game of trees) от разработчиков OpenBSD - поддерживает все основные команды git и совместим с git репозиториями.
> зато хг или тот же свн могут просто работать без ненужных переусложнений,Работать - это громко сказано. Потому что вот именно контроль версий в гите получается лучше.
Хг как раз даёт прозрачность и удобство cli. Продолжаем жевать кактус всей индустрией..
> Хг как раз даёт прозрачность и удобство cli.Для каких-то непрограммистов - может быть. Для програмеров гит - как родной. Что там не делай, а обнаруживаешь что давно хотел делать именно это, именно так. Потому что это логично и эффективно на самом то деле. А вон то - более быстрые лошади для тех кто с SVN расстаться не может. Странно что они вожжи к рулю не крепят для эмуляции конной тяги.
Почему вы решили, это Mercurial сдох? Разработка продолжается, пакеты обновляются, утилита работает, багов в повседневной работе не встречается, довольно большое сообщество. Некоторые облачные сервисы отказались от него? Ну так то бизнес.>несмотря на непрозрачность и неудобство CLI
>решает поставленную задачу вполне сносноНу хоть честно признаете, что как инструмент Git довольно неудобен и переусложнен.
Mercurial очень хорош для новичков, а перейти с него на ограниченное подмножество Git (которым пользуется 99% сидящих здесь экспертов) это дело буквально одного дня.
> Почему вы решили, это Mercurial сдох?Потому что его практически все хостинги вынесли, что намекает на востребованость фичи. А между собой там можете хоть голубиной почтой файлы слать, всем похрен.
> облачные сервисы отказались от него? Ну так то бизнес.
Да, поддерживать второй код - который сильно более проблемный, делает то же самое, но хуже, и нужно полутора чудикам, желающих и правда не нашлось.
> Mercurial очень хорош для новичков, а перейти с него на ограниченное подмножество
> Git (которым пользуется 99% сидящих здесь экспертов) это дело буквально одного дня.Только они потом в нем инвалидами с искалеченой психикой и остаются, так и не познав что DVCS это оказывается не улучшенный свин а совсем другой воркфлоу по нормальному.
Просто вспомни язык на котором написан меркуриал и ты сам все поймешь...
его сейчас активно переписывают. на хрусте...
Мне лично глубоко пофиг на чем написано ПО, если оно прекрасно выполняет свою задачу и не требует для своей работы сотен мегабайт дополнительных библиотек. А вот к блобу под названием git у меня есть конкретные и не очень приятные вопросы...
Огласите, пжлст.
Есть chg
Только тем что существует github.
> чем оно лучше меркуриал?Да всем блин.
Очевидно, что у каждого инструмента есть свои достоинства и недостатки.Git хорош для больших и огромных проектов, но переусложнен для небольшого проекта. Он быстр, но у него широкая и запутанная система команд.
Mercurial прост, его команды интуитивно понятны и хорошо подходит для небольших проектов. Он не так быстр, но на практике для большинства проектов это не так важно.Так сложилось, что Git вышел раньше и имеет сильнейшую поддержку от сообщества Linux, что позволило ему стать доминирующей VCS несмотря на вопросы к его эргономике. Но это не значит, что Mercurial не является вполне рабочей альтернативой, особенно для начинающих. Во многих компаниях это основная VCS.
и что все так любят гит? программа 20КБ, папка гит вест 100МБ. какого фига?
Не нравится - можно юзать svn тогда.
опенсорс, идите и разберитесь, Яков
git gc
sudo apt remove gitкоманда полезнее
Ты останешься с той же самой репой, но без инструмента для работы с ней. Молодец.
Ну тогда уж apt purge, в то так останутся конфигурации какие-нибудь, пацаны на районе не поймут
Гит всё правильно делает.
Ты, наверно, не догадался, как сделать, чтобы не весило. Куда важнее, чтобы не скачивало чисто для компиляции, конечно. А вот в целях разработки может быть выгодно иметь полную копию данных.
Я начал новый проект в kdev и сделал тудапару коммитов. Мне некогда разбираться какого хрена очередная неведомая ёкнутая технология гадит в мою жизнь. Снёс нафиг - мне хватает и rar/tar/7z *.cpp раз в день.
Значит вы так и не поняли что гит - это не только про резервные копии
git - Это вообще не про резервные копии, как и любая VCS. Резервные копии никто не отменял
Если тебе хватает zip, и подобных для своей разработки,
значит твой проект пока еще не вырос чтобы его в
git перекладывать..
Так ты даже не программист.
Смешно сравнивать с geany. Но просто гонит, в kdevelop (если это конечно он подразумевался, а то непонятно) нет такого поведения. Скорее всего левые данные попали.
Да, о нём. Там багов предостаточно (даже порой больше на квадратный килобайт чем в самом линуксе), но это, в принципе, довольно годный искоробочный ИДЕ, который позволяет что-то делать.
Есть подозрение что там каждый раз генерились тонны какого-нибудь browse info от гигабических библиотек, использованных в проекте, но мир никогда не узнает. Снёс к хренам.
Хочу посмотреть как ты аналог git bisect сделашь в зип архивах, чудак :). Да, прикинь - я гасил баги в совершенно неизвестном мне коде понятия не имея что ищу и где это.Вот прям найдя offending commit с точностью до него - и уже предметно раскуривая на очень небольшом сегменте кода, точно зная кто, когда и где вкатил код после которого что-то пошло не так. А чтобы сегмент кода небольшой был - таки да, кодер должен быть одупляемым. Ты этого пока еще не понял просто.
Тем не менее, пару хинтов:
1) Комитить имеет смысл относительно консистентные состояния имеющие смысл. Как минимум это должно компиляться в общем случае. Иногда факапы случаются но лучше без них - при bisect можно о таком решении пожалеть будет.
2) Однако комитить стоит мелко и часто, дабы иметь возможность гранулярно откатывать неудачные результаты своего редактирвоания, экономя себе время. Ну вот поредактировал фичу, отрефакторил, думал улучшить а работает как полный трещ, вон там стало сложнее, и вообще не оправдало себя. Ну тогда сделать чекаут более старой версии и плясать от нее, списав в утиль МИНИМУМ. А если неделю впашки в утиль - обидно и неэффективно, да?!
3) В целом имеет смысл считать что комит это какая-то фича или фикс в относительно атомарном виде. Там должно быть что-то такое по задумке. И искусство кодинга и руления гитом в том чтобы этот баланс нащупать, тогда очень круто получается.
Яков, вы на пару со Стахлем себя просто напросто дискредитируете своими псевдо полезными хобби
> мне хватает и rar/tar/7z *.cpp раз в день.Значит git тебе не нужен. Более того, вреден и будет всё портить.
> Снёс нафиг - мне хватает и rar/tar/7z *.cpp раз в день.Ну ты капец разработчик. Твою жизнь не надо гадить - ты ее сам себе уже так изгадил что дальше некуда, остальные без шансов так тебя заякорить, чудак.
Понимаешь, я вон там комиты вешаю на каждое изменение которое может сломать что-то или потенциально подлежит откату. Поэтому если мне на полпути что-то в рефакторе не понравилось я могу половину успешных наработок сдернуть а половину аннулировать. И для чего-то такого системы контроля версий и нужны. А с твоими раржыпегами оно при активном оперировании в таком режиме начинает жрать кучу места даже для небольших проектов. А в гите так то только дельта с изменениями хранится, и вот это может быть довольно эффективным.
Так, на подумать, гит кернела СО ВСЕЙ ИСТОРИЕЙ занимает примерно 1.6 гига. Распакованное из него текущей версии - примерно столько же весит. Удвоение веса проекта за возможность шариться в его истории с начала времен не так уж и плохо, как по мне.
А в вооооон той фирмваре .git весит "аж" 500 кило. А там история довольно насыщенной жизни проекта за три года. С суммарным весом файлов на 400 кило. Только 3 года назад оно не имело ничего общего с вот этим кодом. Ну, почти. Наверное логично что какая-то дельта должна быть, да? Что ты сделал чтобы сто мегов туда вкатить - кто тебя знает.
Полагаю что с .gitignore вы не разбирались
Запилил, конечно. Это самое важное в гите. )
Значит ты что-то не так делаешь. Скорее всего когда-то ты хранил в git бинарники, в рабочей директории почистил, а в истории нет.
Просто git предназначен для разработки, а не для "медитации" на занятое место на диске.
Если ваша цель не разработка, а что-то другое воспользуйтесь соответствующими инструментами
> Просто git предназначен для разработки, а не для "медитации" на занятое место на диске.Да он место на диске особо не жрет без хорошего на то повода, как то огроменной дельты относительно оригинала в куче версий. Скорее комитнули туда какой-то хлам, типа объектников или бинарей программы.
> Просто git предназначен для разработки, а не для "медитации" на занятое место на диске.Да он место на диске особо не жрет без хорошего на то повода, как то огроменной дельты относительно оригинала в куче версий. Скорее комитнули туда какой-то хлам, типа объектников или бинарей программы.
Он же хранит всю историю коммитов, и все ветки. У тебя может быть там миллион веток
Гит хранит объекты, а не ветки. Ветки это просто txt со значением SHA-1. По идее git prune сносит все объекты, на которые не ссылается ни одна ветка. Поэтому удаляем лишние ветки и сносим. Но ещё история ссылок есть, её сначала тоже снести нужно.
Ничего не знаю, на 64 битной gentoo:$ ls -h $(command -v git)
-rwxr-xr-x 142 root root 3,6M фев 11 07:49 /usr/bin/gitНа винде git без *nix-ового окружения не может, так что ваши 100МБ это плата за использование пропроетарного ПО. И да, о WSL2, вам явно не рассказали.
Не засирай репозиторий ненужными блобами и будет тебе щастье.
> Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток.А почему не самой?
Антимонопольщики замучают.
Что не мешает быть ему статистически самой популярной VCS
Какое отношение антимонопольный комитет имеет с свободному ПО? Они что, плату за воздух взимать будут?
В поддержке SHA256 до сих пор никаких подвижек.
Работа остановилась. Коммитить не могу. git'ом пользоваться невозможно.
Дайте поддержку SHA256 уже, наконец!
> В поддержке SHA256 до сих пор никаких подвижек.Совместимость однако тянет...
BTW, fossil-scm давно на sha384
Технологии ради технологий.
А смысл от sha384? У настоящих джентльменов есть только sha1, sha256 и blake3
аппаратно командами процессора поддерживается только sha1 и sha256. При этом sha1 сильно быстрее. С учётом того, что подбор коллизии (стоимостью 100к$) как атака мало актуально для гитовских реп -- можно не париться.
А у кого-нибудь получалось подобрать такую коллизию? Не pdf с рандомным мусором, как у Гугла, а валидный гит-коммит? Там ведь надо чтобы совпало вообще всё, включая размер файла. И ещё бы неплохо, чтобы это компилировалось (смысл рандомный мусор пихать?)Я не криптоаналитик, но мне кажется это малореальным.
Подбор коллизии -- это именно подбор *одновременно* двух РАЗНЫХ наборов данных с одинаковым, но заранее неизвестным хешем. Подбор левых данных с целью получить заранее известный хеш -- это уже подбор прообраза и совершенно другая задача. Если для мд5 коллизии подбираются за секунду то для прообраза вынь да положь перебор всех 2^128 вариантов. Потому я и говорю -- паника по поводу sha1 бессмысленна, паникуют только те, кто не в теме.линкс релейтед: https://en.wikipedia.org/wiki/Collision_attack https://en.wikipedia.org/wiki/Preimage_attack
Плюс, в случае коллизии git берет _первый_ коммит с данным хэшем.В общем, вообще не вижу о чем беспокоиться. Есть масса куда более реализуемых способов нагадить.
Мне вот интересно, вот каждую версию столько плюшек появляется, их вот прям все используют? Или ограничиваются стандартным набором?
большинство разрабов которые сидят на гит тупо коммитят через VS Code или браузер)) им пофиг
Потом открываешь историю комитетов, а там fix fix fix again
Какие сложные вещи люди делают в git?
Я кроме commit, push, merge ничего не делаю, изредко только файл или коммит из другой ветки забираю и пытаюсь по idea git history понять зачем какую-то фигню делали 3-5 лет назад
Попробуй это сделать без гита
Без системы контроля версий это будет свалка кода, которую невозможно поддерживать.
Там и так свалка, но с ней с трудом можно что-то делать
Гитом пользуются потому что github. Ваши операции проще делать в практически любой другой VCS.
Кстати github скоро невозможно будет использовать, потому что нужно будет предоставить справку об отсутствии судимости и доказательство с мокрой печатью что ты это ты, а не кто-то другой. И причин использовать git не останется, кроме самой привычки его использовать.
Тогда появятся отечественные аналоги)
Именно так, удивляет как хомячки поглотили эту мульку с 2хфакторной аутентификацией. Свободные люди этим никогда пользоваться не станут
rebase blame reflog log reset checkout
> rebase blame reflog log reset checkoutЭллочки людоедки не могут в git bisect :). А напрасно, крутейшая штука. Можно картинно загасить баг в коде который вы впервые в жизни видите и ничерта в нем не смыслите. Когда DVCS такой хинт подогнал, кто угодно - офигенный кодер. Ведь вам по сути показали где баг, остается только починить.
Это же просто набор команд, а не что вы с этим делаете
Checkout вообще одна команда на кучу операций
> В скрипт git-jump добавлена поддержка редактора EmacsВау! Ждем обновления magit.
Кому больше нравится система команд Mercurial, существует полезная штука - плагин Hg-Git (https://hg-git.github.io/), который позволяет работать с Git-серверами через интерфейс Mercurial.