Занятная идея. Сначала запихнуть все исходники в один моно-репозиторий, а потом заморочиться с checkout-ом по частям. Почему бы сразу-то на части не поделить?
Я не знаком с особенностями производства софта в MS, пока мне кажется, что это - инвестиции, доработка git ради более эффективной работы в будущем с чем-то еще, нежели для практической пользы сейчас.
Про развитие Git-LFS нигде ничего не сказано, а работа git с бинарями - это, имхо, его больное место.
А известно что-либо об алгоритме распознавания отпечатков пальцев? Думаю, он тут должен быть специфический из-за того, что предполагается, что обладатель телефона будет активно работать руками.
У меня летом постоянная проблема: если активно пользоваться строительными инструментами или садово-огородным инвентарём, телефоны перестают распознавать мои отпечатки. Ну, т.е., дачный сезон, стройка, грядки - помахал молоктом, покопался в земле - и рисунок пор на коже, не говоря уже о папиллярном, меняется до неузнаваемости. Перчатки не помогают. Только мизинец левой руки (я правша) более-менее в сохранности остаётся :).
За последние несколько лет в моих руках побывал не один смартфон, на всех я активно пользовался анлоком с помощью отпечатков пальцев, и везде была одна и та же проблема.
Нет, просто забытых. Я ж говорю, человек просил меня означенную ветку оставить, т.к. там было что-то для него ценное, что он собирался доделать как-нибудь потом, и вот это потом никогда не наступало.
И проблем больше нет. Во-первых, проект давно завершен, во-вторых, я там уже не работаю.
Проблемы с организацией воркфлоу были, это точно. И обилие веток было наименее существенной из них. Еще имелась копия нашего репа в Perforce, с довольно сложными правилами коммитов туда и периодически прилетающими правками оттуда, которые как правило всё ломали. Я с со всем этим пытался бороться, но встречал непонимание со стороны остальных, вызванное, в частности, недостаточным умением членов команды работать с git (как я сейчас думаю, оглядываясь назад).
Выгорел и ушел в другой проект. Теперь вообще работу поменял.
Я пропустил звено в переходе от форков к монорепозиторию с виндой, а отредактировать комментарий уже не получается.
Думаю, что все эти пляски с сортировкой веток и коммиттеров связаны как раз с этим. В MS запихнули все исходники винды в один git-репозиторий, и под это дело допилили виртуализацию staging area, сортировки и sparse checkout.
После слияния - удаляли, разумеется. Часть руками, часть автоматом. Если бы не кнопка "Delete merged branches", веток было бы еще больше.
Еще были эксперименты в отдельных ветках, которые так никуда и не пошли. Я несколько раз кликал клич, мол, "ув. коллеги, удалите всё, что вам не нужно". Что-то удаляли, что-то оставалось ("оставь, я потом доделаю!". "потом" не наступало).
В общем случае нет, не то же самое. Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность. И так у каждого участника по копии уже есть.
Однако, и всю винду целиком в один монореп запихивать - это тоже очень странно.
Подход Гугла к хранению исходников Android мне нравится больше. ROS2 примерно так же хранит свой код (https://github.com/ros2). Там пачка относительно небольших репозиториев, в каждом хранится отдельная логически законченная часть прокета. И есть https://github.com/dirk-thomas/vcstool который выкачивает или переключает всю эту пачку разом на нужные коммиты, в зависимости от того, что сказано в YAML с конфигурацией
В общем я за разумное укрупнение или дробление там, где это реально нужно.
Думаю, что форки - это всё же не для командной работы, а для возможности иметь своё "такое же, но с перламутровыми пуговицами". Команды и на гитхабе в один реп коммитят.
Один из моих проектов с командой из 5-6 человек за 3 года оброс 400 с лишним ветками. Размер репа составлял больше 1Гб.
Другой проект длился 6 лет, разрабатывался двумя командами из 8 и 11 человек. Тоже несколько сотен веток запросто накопилось. Два или три раза переезжали в другой репозиторий: останавливали коммиты в текущий, переводили его в read-only и заводили новый из текущего слепка. В этом случае еще большие бинарные файлы (ассеты для UE4) и Git LFS прибавились.
Если моя фича зависит от васиной, то, чтобы проверить свои результаты, я должен буду притянуть в свой форк васину ветку, ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Если Вася где-то не прав, и я могу это исправить, то получается еще одна ветка.
Один и тот же человек из раза в раз повторяет одну и ту же ошибку? Или это разные люди? Если один и тот же, то откуда характеристика "очень неглупый"?
А пробовали над проблемой работать? Например, лекцию прочесть, порешать олимпиадные задачки?
А что за скрипт? Мне тоже периодически приходится, но я X-сервер перезапускаю Ctrl-Alt-BSом.
Не особо удобно, приходится всё заново перезапускать.
Нашёл на askubuntu такое
И ещё был вариант с killall
У Вас так же?
Тут как-то plastic scm хвалили...
Upd. Поискал, почитал. Он серверной и не в РФ, возможны проблемы.
Да я верю :) А чего они его тогда называют the largest on the planet? "Сам себя не похвалишь?.."
Занятная идея. Сначала запихнуть все исходники в один моно-репозиторий, а потом заморочиться с checkout-ом по частям. Почему бы сразу-то на части не поделить?
Я не знаком с особенностями производства софта в MS, пока мне кажется, что это - инвестиции, доработка git ради более эффективной работы в будущем с чем-то еще, нежели для практической пользы сейчас.
Про развитие Git-LFS нигде ничего не сказано, а работа git с бинарями - это, имхо, его больное место.
Там еще упоминается про 2000 активных коммиттеров и десятки пушей одновременно.
А известно что-либо об алгоритме распознавания отпечатков пальцев? Думаю, он тут должен быть специфический из-за того, что предполагается, что обладатель телефона будет активно работать руками.
У меня летом постоянная проблема: если активно пользоваться строительными инструментами или садово-огородным инвентарём, телефоны перестают распознавать мои отпечатки. Ну, т.е., дачный сезон, стройка, грядки - помахал молоктом, покопался в земле - и рисунок пор на коже, не говоря уже о папиллярном, меняется до неузнаваемости. Перчатки не помогают. Только мизинец левой руки (я правша) более-менее в сохранности остаётся :).
За последние несколько лет в моих руках побывал не один смартфон, на всех я активно пользовался анлоком с помощью отпечатков пальцев, и везде была одна и та же проблема.
А что делать, если аккумулятор несъёмный? Есть рецепты?
Нет, просто забытых. Я ж говорю, человек просил меня означенную ветку оставить, т.к. там было что-то для него ценное, что он собирался доделать как-нибудь потом, и вот это потом никогда не наступало.
И проблем больше нет. Во-первых, проект давно завершен, во-вторых, я там уже не работаю.
Проблемы с организацией воркфлоу были, это точно. И обилие веток было наименее существенной из них. Еще имелась копия нашего репа в Perforce, с довольно сложными правилами коммитов туда и периодически прилетающими правками оттуда, которые как правило всё ломали. Я с со всем этим пытался бороться, но встречал непонимание со стороны остальных, вызванное, в частности, недостаточным умением членов команды работать с git (как я сейчас думаю, оглядываясь назад).
Выгорел и ушел в другой проект. Теперь вообще работу поменял.
Я пропустил звено в переходе от форков к монорепозиторию с виндой, а отредактировать комментарий уже не получается.
Думаю, что все эти пляски с сортировкой веток и коммиттеров связаны как раз с этим. В MS запихнули все исходники винды в один git-репозиторий, и под это дело допилили виртуализацию staging area, сортировки и sparse checkout.
После слияния - удаляли, разумеется. Часть руками, часть автоматом. Если бы не кнопка "Delete merged branches", веток было бы еще больше.
Еще были эксперименты в отдельных ветках, которые так никуда и не пошли. Я несколько раз кликал клич, мол, "ув. коллеги, удалите всё, что вам не нужно". Что-то удаляли, что-то оставалось ("оставь, я потом доделаю!". "потом" не наступало).
В общем случае нет, не то же самое. Git изначально задумывался как инструмент для коллективной работы над одним кодом.
Кстати, про ci-build еще забыли. Его обычно для репозитория индивидуально настраивают. Т.е. для каждого форка своё придётся делать.
Я не отрицаю, что над одним проектом можно вести работу в разных форках, и потом как-то их сливать. Но мне кажется, что форк в данном случае лишняя сущность. И так у каждого участника по копии уже есть.
Однако, и всю винду целиком в один монореп запихивать - это тоже очень странно.
Подход Гугла к хранению исходников Android мне нравится больше. ROS2 примерно так же хранит свой код (https://github.com/ros2). Там пачка относительно небольших репозиториев, в каждом хранится отдельная логически законченная часть прокета. И есть https://github.com/dirk-thomas/vcstool который выкачивает или переключает всю эту пачку разом на нужные коммиты, в зависимости от того, что сказано в YAML с конфигурацией
В общем я за разумное укрупнение или дробление там, где это реально нужно.
Авторы (или кто-то за авторов) объясняют это тем, что git не вывозит такого размера кода. Точнее, раньше не вывозил, а теперь может.
Вот тут пишут, что MS все исходники винды в git monorep запихнула. Для этого все нововведения и понадобились
Думаю, что форки - это всё же не для командной работы, а для возможности иметь своё "такое же, но с перламутровыми пуговицами". Команды и на гитхабе в один реп коммитят.
А иначе тупо не понятно, где автора искать.
Это GitHub так вывернулся. Про Gitlab, Bitbucket, Gitea, gogs и прочие хостинги мне ничего не известно.
В gerrit, насколько я помню, вообще нет понятия форка.
Предлагаете заинтересованным покупать GitHub Enterprise?
Для этого придумали всякие git-flow, github-flow, gitlab-flow.
Чтоб ветка master была одна, репозиторий тоже был один, и было единственное место, куда складывается проверенный и оттестированный код.
(в сторону) блин, да что же их "Хижина дяди Тома" остальным-то жить спокойно не даёт?
Видимо, речь про Microsoft и запихивание всех исходников Windows в монореп git. Там в последнем предложении ссылка на английскую статью про это.
Один из моих проектов с командой из 5-6 человек за 3 года оброс 400 с лишним ветками. Размер репа составлял больше 1Гб.
Другой проект длился 6 лет, разрабатывался двумя командами из 8 и 11 человек. Тоже несколько сотен веток запросто накопилось. Два или три раза переезжали в другой репозиторий: останавливали коммиты в текущий, переводили его в read-only и заводили новый из текущего слепка. В этом случае еще большие бинарные файлы (ассеты для UE4) и Git LFS прибавились.
Если моя фича зависит от васиной, то, чтобы проверить свои результаты, я должен буду притянуть в свой форк васину ветку, ребейзнуть свои коммиты на неё или слить мою ветку с васиной.
Если Вася где-то не прав, и я могу это исправить, то получается еще одна ветка.
Не обязательно. Если васина фича зависит от моей, а моя - от васиной, то у каждого в репе будут чужие ветки и по два remote, свой и товарища
Приходим к выводу, что двоим-троим всё же удобнее в один реп коммитить, а не в три.