> ну ты так можешь даже вообще без vcs, только результатом будет два
> (или больше) параллельных проекта. Которые потом один хре н мержить с кро вью и ки шками.Дай чудаку стеклянный Х - он и Х разобьет и руки порежет. Весь пойнт в том чтобы каждый пилил свою фичу условно-независимо и не лез в чужие огороды без нужды. А если влез - оформлял мержабельно.
> Клинит -то тебя не vcs, а реальное отсутствие/поломанность/несоответствие реального кода,
> который кто-то, не ты, должен еще пере/написать.
В случае git обычно применяются workflow, когда пилят и мержат "фичу", а место где народ координирует усилия - консистентно. У свинарей то полурабочая фича в проекте то гемор у разработчика - нормально управлять историей не получается. А в гите можно все и сразу. Более того, в гите можно организовать нормальный preview фичи из бранча вон того разработчика, куда более вменяемо чем бранчи в свине, которые в свине бесполезны. Свин к тому же не масштабируется и нагружает PM/мержера по поводу и без.
>> 2) Настолько, что пару коммитов можно нарисовать даже на природе и без интернета.
> но зачем? В нормальной, опять же, ситуации - либо ты почти единственный
> разработчик (хотя бы своего куска),
А затем что пришло удачное решение - записал. А через 2 дня поздняк метаться, все забудешь уже.
> либо без code review все равно не примут - поэтому нарисованное на природе
> вполне можно и в working copy оставить.
Только с гитом у человека нормальный контроль версий под рукой. Он и коммитить может, и локальные бранчи создавать, и по ревизиям шариться, не только своим, а если баг вылез то и bisect устроить, по всему проекту. Не перекачивая весь проект 20 раз с жуткими тормозами.
> для linux kernel - да, критично, "большой" (смехотворно) патч не примут вообще.
У Linux kernel налажены разумные и эффективные воркфлоу для большого проекта с большой командой, даже распределенной. Корпорашки стали просекать и так смешно тужатся это содратью. Что только не придумали со всякими скрам-бананами.
> Ну так это проблемы коммитеров в линукскернел - зачем вот оно
> авторам clang, которых по пальцам одной руки пересчитать?
Во первых, их побольше. Во вторых, у них есть гит-зеркало и многие из - давно орудуют гитом, чтобы хоть немного скрасить паршивость svn как системы контроля версий. В третьих, паршивые девтулсы не способствуют пополнению рядов разработчиков. А svn плохой девтул, потому что управление версиями никакущее.
> требуя хранить все терабайты локально, с момента сотворения мира,
Во первых, хранятся эффективно, с дельтами и сжатием. Так что сжатое хранилище у линуха весит примерно как 1-2 распакованных версии ядра. Только там вообще все, начиная с 2.6.9, чтоли. И всегда можно сгонять на машине времени назад в момент когда бага возможно еще не было.
Во вторых, никто ничего не требует - клонируй с depth=1 и будет тебе репа как у svn. Но это глупо, если планируется сколь-нибудь активная работа с проектом. Этим обычно страдают адепты клуба "вступайте и кампелируйте". Об их удобстве разработчики не заботятся, разумеется. Разработчики о своем удобстве заботятся.
> Кстати, по этой самой причине, качалка-то там как раз вполне себе ничего
> так, не знаю, где еще более продвинутая.
Качалка умеет дельты, но докачку не умеет. Поэтому на начальный синк может потребоваться поднапрячься, но дельты потом качать можно хоть GPRS. Вот разработчики и не напрягаются, раз в жизни нужный проект можно на толстом канале утащить.
> Но опять же - если ты не коммитер ядра, нафиг оно тебе?
А затем, что когда я вкатил в мои системы новое ядро и что-то отвалилось (у меня встройка, не тестируется на хомяках) - делаю git bisect и быстро вывожу баг на чистую воду. Как минимум regressions и newly introduced. А когда проблема вычислена - маневрировать просто. Остальные варианты поимки ядерных багов сильно затратнее.
> сравнивал - когда это не твой проект - с svn оно вышло гораздо проще.
> Хотя и с единственным инструментом в виде blame (и без понятия, blame что).
Свин на каждый чекаут перекачивает полинтернета и вообще тормозит. Поэтому получается все это медленно и печально. Если система контроля версий плохо контролирует версии - зачем она нужна?
> сочувствую...
Yolo, it WORKSFORME. For fun and profit.
> Рассказать тебе про историю linux-net team времен ank@? Которые использовали svn во
> времена когда у Линуса основным рабочим инструментом был pine
А зачем мне все эти истории наскальной живописи?
> ну уже очень надо было работающую сеть, а другой вменяемой команды
> не предвиделось ( и нынче нету).
Ну а Линус вот еще своим соратникам нормальную vcs подогнал на нормальных условиях. И чего-то все пользоваться стали, в том числе и далеко за пределами ядра. Гитхаб и прочие гитлабы, центрированные на работу с сорцами а не файлокачание быстренько задвинули всякие сорсфоржи, где кроме файлопомойки и нет ничего вменяемого, а разработчикам файлопомойки как собаке пятая нога.
>> Ты к нему и близко не стоял, вместе со своей командой лузеров.
> ну значит мне git и не нужен, как, собственно, и большинству,да.
Про большинство ты прав - они программить не умеют. Зачем им vcs? Версионировать фоточки котят? Лол, там одна версия, она же финальная.
> Ну нету у меня задачи автоматизировать приляпывание патчей из почтового клиента. А
> исходная идея git как раз в этом и состояла.
На самом деле это всего лишь один из множества вариантов обмена патчами. Есть и ряд других, на все случаи жизни - от флоппинета до гитхаба. Гит как таковой ничего жестко не навязывает. Где на гитхабе и прочих гитлабах патчи в емыле, чудак? Гит можно хоть по RFC1149 использовать. Оформил package, прикрутил - и полетели патчи! :)
