Comments 31
Плюсы: интересные фичи. Минусы: размер(3-5Мб против 35Мб).
Меня смущают инвестиционные фонды, которые вывалили 17млн. Как-то же они должны деньги отбить?! Получается, скорее всего будет эктерпрайз версия и комьюнити.
Чет не совсем понятно зачем все это... какие реальные проблемы он хочет решить? Есть хоть что нибудь? Почему то миллионы разработчиков используют и не жалуются... вроде бы. Или, опять же, вайбкодерские нужды?
Как зачем?
Чтобы привлечь 17 миллионов баксов. Зачем же ещё)
Не жалуются только пребывающие в мире розовых пони. Гит на самом деле лютое говно. Другое дело, что, как правило, миллионам разработчиков не предоставляют права выбора.
А что не лютое говно и по каким критериям? Потому что заявление без аргументации это такое себе. По факту же пока git победил в эволюционной гонке систем контроля версий.
все лютое г, да.
гит не удобен для геймдева, где много бинарных данных. lfs это костыль. гит не поддерживает папки, только файлы, юнити генерит для папок меты, и начинается то стирание их то создание на разных машинах. в гите левый слеш и правый, это разные вещи, файлы лежат технически в разных папках, хотя на целевой машине это один и тот же файл. в гите нет режима среза, приходится постоянно делать транкейт, потому что приходится выкачивать все изменения файлов, но наверно эту проблему решает deep параметр. вот, это все что вспомнил.
мы в итоге сидим на свн, а там свои проблемы.
вот собрали бы денег и создали что то типа Plastic, который купила юнька и втюхивает за бабло.
вот там есть режим для художников, артистов - последний срез, как в свн и есть полный режим как в гит.
взяли все хорошее из гита и свн, ну и видимо других сурс контролов.
Так он не эту проблему решает. Он зачем-то решает проблемму online мерджа без комита. Кому и зачем это надо совершенно непонятно.
гит не удобен для геймдева, где много бинарных данных
ЕМНИП, в геймдеве доминирует helix, так что это плохой выбор инструмента, а не плохой инструмент
гит не поддерживает папки, только файлы, юнити генерит для папок меты, и начинается то стирание их то создание на разных машинах
.gitkeep, .gitignore, итд
в гите левый слеш и правый, это разные вещи, файлы лежат технически в разных папках, хотя на целевой машине это один и тот же файл
проблема разных ОС у участников, ФС windows и macos регистронезависимы поэтому такое всплывает
в гите нет режима среза, приходится постоянно делать транкейт, потому что приходится выкачивать все изменения файлов, но наверно эту проблему решает deep параметр
deep indeed
Так и получается, что использовать git в геймдеве выглядит как попытка закрутить шуруп молотком.
никто не понимает проблему папок, каждый раз мне тыкают гитигнор и гиткип )
итак.
если переименовать папку, то старая удалится а новая появится.
если переименовать дерево папок, или пепенести какую то либу или плагин, тоже самое, удалится куча папок и создасться куча папок других.
юнити создаст новый мета файл для каждой новой папки и удалит мета файлы для старой папки.
т.е. если у нас была библа и мы решили ее перенести, то в гите, помимо кучи нужных файлов, будет куча созданных метафайлов и куча удаленных метафайлов.
далее, два человека обновляются.
юнити смотрит - ога, метафайлов папок нет, а папки то есть локально!!!
и создает кучу мета файлов которые были удалены!
теперь когда люди начнул заливать, у них будут кофликты.
а если я обновлюсь, то у меня папок нет! и юнити снова удалит метафайлы! и так по кругу.
никто не понимает проблему папок, каждый раз мне тыкают гитигнор и гиткип )
Потому что то изначально git работает в unix-системах, где "все есть файл", а пустая директория это ничего.
Далее очень плохо написано, что не понятно из-за чего возникает конфликт: если файлы были просто перенесены, git видит это как rename, другое дело что может быть проблема когда переносятся бинарные файлы (.so, .dll, etc.), то нужно в gitattributes явно указывать особенности обработки их изменений, чтобы git понял, что это был именно rename, а не deleted+created.
По прежнему перечисленные проблемы выглядят как неправильный выбор инструмента + неумение им пользоваться
В Git давно есть и "срез". И по глбуине и по дереву папок. Можно скачать только чаcть worktree на нужную глубину и полноценно с ним работать. Передаваться туда-сюда и храниться в локальном репозитории реально будет только, что указано. Результат будет выглядеть так, как будто у вас полный репозиторий выкачан. А так пожалуйтся - пуште, пулте, комитите - и для всего мира это будет выглядеть, как работа с полные репозиторием. Только, естественно, нельзя будет править части worktree, которые не выкачаны, но можно в любой момент докачать нужное.
Короче, всё есть, нужно просто уметь пользоваться.
А на что именно вы жалуетесь? У меня гит работает отлично, покрывая мои потребности, хотя розовых пони никогда не видел.
Фундаментально, гит - низкоуровневый инструмент. Далее не вижу постулатов, о которых можно было бы дискутировать. В плане изменений есть два вектора:
другой UI. Тех же CUI есть несколько приятных.
другое взаимодействие со внутрянкой. А внутрянка: иммутабельное хранилище, контентная база данных, если его использовать как задумано
ИИ сможет галлюцинировать кодом в многопоточном режиме. Удачных ревью...
Миллионы разработчиков пользуются, жалуются, но альтернатив нет. Он хочет дать альтернативу. В статье описан основной смысл - должна быть не просто локальная и удалённая ветка, а координация между работающими с репозиторием, в реальном времени. Типа гуглодока, где ты видишь, что успели изменить с момента Х
Плюсом / параллельная работа с ветками, без переключения и стешей. Ты просто работаешь тут, а потом правишь в другой, а потом продолжаешь работать тут
Ну и по мелочи
А для первого есть git pull, а для второго git workspaces.
Надо ещё написать такую альтернативу офису, чтобы в ней слова писать можно было.
Не может быть "координации" одновремено с консистентностью и атомарностью. Для этого и придуманы push/pull/merge. Чтобы история оставалсь, атомарность переходов между состояниями и общая сбтабильность состояния репозитория.
Без этого это не GIT, а "общая папка" называется, и это уже вовсе не система контроля версий.
я так же как миллионы других разрабов выучил 6 команд и стараюсь копировать репозиторий в бэкап почаще, чтобы ничего не испортить
А jujutsu не то же самое?
не ну классно выглядит, но я бы ожидал, что это какой-то его пет проект дома... а тут какие-то инвестиции упоминаются - непонятно, а что там денег-то стоит.
Но сам инструмент проектировался под совершенно другую модель: один человек, один терминал, одна ветка, линейный поток изменений.
Бесконечное кол-во человек, быстрые независимые ветки, асинхронный поток изменений с точками детерминированной синхронизации состояния.
но и то, что делают другие агенты и разработчики в реальном времени. Конфликты мёржа — до того, как они появились, а не после.
Квантовый гит? Где состояние "до слияния" в суперпозиции, которые они обязаны как-то схлопнуть к детерминированному состоянию? Причем "квант" можно понимать в обоих значениях, за этим маркетинговым булшитом может крыться повышенная гранулярность.
И как я написал выше, это похоже лишь надстройка, другой UI со свистелками.
Они там сговорились что ли? Другой директор Гитхаба же совсем недавно выпускал другого убийцу Гитхаба https://entire.io (и поднял на порядок больше).
Если она умеет нормально мержить списки, в которых в одной строке что-то менялось, а потом в следующей, а git пишет конфликт, когда его нет, то её стоит рассмотреть. Из-за этого ввели висящие запятые для JS-объектов у себя в коде - намного меньше конфликтов и понятнее изменения. В YAML подумываю о пустых строках между элементами списка. Какой-нибудь часто меняющийся список фича флагов даёт гарантированный конфликт всегда. Чего бы вообще семантический мердж не делать, понимая где списки, которые можно безболезненно сливать и даже реордерить?
Конфликты мёржа — до того, как они появились, а не после.
Это как? Они предвидеть будут, что кто-то напишет что-то?
У гита есть известные проблемы. Из того что я знаю: Работа с бинарными данными, работа с очень большими репозиториями, cli интерфейс, работа на виртуализованых файловых системах, ACL.
Но под их решение никто денег не даст естественно.
Работу с бинарными данными уже сильно улучшили и ускорили. Работу с большими репозиториями тоже. У мaйков и ещё нескольких компаний моно-репозитории уже террабайтные с worktree в десятки (сотни?) гигабайт и всё работает шустро даже слабых на машинах разработчиков. Я как раз недавно с этим разбирался.
Уже пять лет, примерно, как всё есть и работает. Просто всем лень учить новые функции и они предпочитают страдать и стенать.
Из реальных проблем сейчас есть только ACL, но там в принципе нет хорошего универсального решения, а если прямо очень сильно надо, то решается костылями на хуках.
Один из сооснователей GitHub поднял $17M инвестиций на то, чтобы заменить Git