После трёх месяцев разработки представлен релиз распределенной системы управления исходными текстами Git 2.52. Git отличается высокой производительностью  и  предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.  Код Git распространяется под лицензией GPLv2+...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64279

• Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:35 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 21:05 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:20 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:35 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 05:34 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:15 , 20-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Анонисссм, 18:38 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,myster, 18:42 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:27 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:15 , 20-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:43 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:06 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:20 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:39 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,zionist, 14:11 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 04:48 , 19-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,xsignal, 18:47 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:53 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 19:05 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 19:12 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 19:14 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,morphe, 23:10 , 18-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:30 , 18-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:53 , 18-Ноя-25
            • Выпуск системы управления исходными текстами Git 2.52,Аноним, 00:39 , 19-Ноя-25
            • Выпуск системы управления исходными текстами Git 2.52,morphe, 01:06 , 19-Ноя-25
              • Выпуск системы управления исходными текстами Git 2.52,Аноним, 06:58 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 06:59 , 19-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,morphe, 07:57 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 19:17 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:06 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:31 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 07:00 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:35 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 01:44 , 20-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:12 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:28 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:48 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:14 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:30 , 18-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,morphe, 23:05 , 18-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:15 , 19-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,12yoexpert, 05:24 , 21-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,_, 00:03 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,morphe, 01:10 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:16 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:06 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:39 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,xsignal, 14:51 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 17:20 , 20-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,_, 01:37 , 20-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:20 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:58 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 02:23 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:40 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Девелопер девяностых, 00:24 , 22-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Сосед с перфоратором, 21:23 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 05:31 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 06:57 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:09 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:43 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 16:07 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 09:59 , 20-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 05:32 , 22-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:32 , 18-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 21:52 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 22:08 , 18-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,morphe, 23:08 , 18-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 23:48 , 18-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:02 , 19-Ноя-25
            • Выпуск системы управления исходными текстами Git 2.52,Аноним, 07:37 , 19-Ноя-25
              • Выпуск системы управления исходными текстами Git 2.52,Аноним2, 10:30 , 19-Ноя-25
                • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:31 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:04 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:08 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:42 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:46 , 19-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:54 , 19-Ноя-25
            • Выпуск системы управления исходными текстами Git 2.52,nn, 08:33 , 20-Ноя-25
              • Выпуск системы управления исходными текстами Git 2.52,Аноним, 08:54 , 20-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,morphe, 23:07 , 18-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:01 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Ангним, 06:31 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 06:56 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 20:05 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:02 , 20-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:23 , 20-Ноя-25
            • Выпуск системы управления исходными текстами Git 2.52,Аноним, 17:31 , 20-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 19:02 , 20-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 05:29 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,morphe, 07:52 , 19-Ноя-25
        • Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 07:57 , 19-Ноя-25
          • Выпуск системы управления исходными текстами Git 2.52,morphe, 07:58 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 01:44 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 02:59 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,12yoexpert, 05:28 , 21-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,penetrator, 01:50 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:12 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 11:51 , 19-Ноя-25
    • Выпуск системы управления исходными текстами Git 2.52,Аноним, 18:43 , 19-Ноя-25
      • Выпуск системы управления исходными текстами Git 2.52,Аноним, 17:28 , 20-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Аноним, 00:47 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Трахтенберг, 03:10 , 19-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,ddwrt, 03:59 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 07:01 , 19-Ноя-25
  • Выпуск системы управления исходными текстами Git 2.52,Аноним, 10:14 , 19-Ноя-25
• Выпуск системы управления исходными текстами Git 2.52,Кошкажена, 05:28 , 19-Ноя-25

Все говорят что раст это плохо. Но ведь runtime зависимости не будет. Problems, officer?

Не отпускает от предыдущей новости?

Проблема в Раст. Его тоже собрать надо. А сколько раз в год он релизится?

Не столь важно, сколько раз. Важно, что ты будешь последовательно собирать каждый предыдущий. НУ, раз уж мы заговорили о сборке. Я вот обновил на 5 версий пару дней назад, что потребовало определённой возни. Проще было бинарный тулчейн стащить, но это не наш метод. Шланги тоже пришлось перебирать и вот это реальная проблема.

1. Проблема со сборкой с нуля. Для этого надо тащить раст и весь его тулчейн. Для source-based дистрибутивов это сильная боль.
2. Доп нагрузка на CI из-за нового тяжелого тулчейна.
3. +1 яп в проект - это увеличение зоопарка технологий. Все прекрасно понимают, что весь С в ближайшем будущем никто не перепишет. Никто не любит скакать между технологиями в проекте.

> 1. Проблема со сборкой с нуля. Для этого надо тащить раст и весь его тулчейн.
> Для source-based дистрибутивов это сильная боль.

Это также проблема для раскрутки платформ с ноля (bootstrap). Пересобирать _все_ версии Rust? С начала времет? Да вы издеваетесь господа!

И не, бинари для новой платформы на деревьях не растут.

самая непонятная программа на свете это git

например? Что там непонятного?

Git - де-факто стандарт в индустрии разработки ПО. Все профессионалы уже давно Git поняли, один ты непонимающий сидишь до сих пор.

> самая непонятная программа на свете это git

Ну значит девелоп софта в тиме - не твое...

> В будущем ожидается переработка на Rust более значительны внутренних компонентов Git и добавление Rust в число обязательных сборочных зависимостей в Git 3.0.

Всё, фризимся на 2.52

Зачем? Если раст будет полноценно поддерживаться в gcc без всякого копролита вроде llvm, то какая разница?

Хм... так-то да.

Это случится… Не скоро, но если случится, то останется решить только вопросы отсутствующего аби (впрочем, плюсы как-то существуют тоже) и динамической линковки.

Ключевое слово - полноценно.

Гугл - хозяин интернетов. Майкрософт - хозяин десктопа. Оракл - хозяин серверов. Вот и стало всё почти как в 90х.

Гит только для ядра годится, потому что писался для этого и Торвальдсом под себя. Для обычных проектов есть куда более удобные системы хранения версий.

> Гит только для ядра годится

А только для линуксового ядра? Или для других ядер тоже годится?

Только линукс.

Не, ну если тебе нравится хэши запоминать и у тебя это хорошо получается, то можно и для других ядер тоже)

А зачем их запоминать? Для удобства манипулирования их же можно сокращать до 8 первых символов, и даже в этом случае можно не запоминать.

Зачем их запоминать? Судя по комментариям опеннетные эксперты гит даже не трогали

Понятно, что на них иногда надо обращать внимание, копировать-вставлять и всё такое. Но запоминать-то их зачем?

Это из той же области как и жалобы, что ipv6 плохо запоминаются.

Когда ищешь что-то и работаешь с историей, приходится запоминать. Да и осминожку мержить удовольствие то ещё (особенно выборочно откатывать).

В одной вкладке терминала git log, в другой git rebase --interactive, который повторяется на ветке до тех пор, пока всё не причешется. В конце сделать ребейз на родительскую ветку и потом можно мержить без выкрутасов.

Возможно, у нас такого треша нет, чтобы нужно было всё время заниматься археологией.

> Когда ищешь что-то и работаешь с историей, приходится запоминать. Да и осминожку
> мержить удовольствие то ещё (особенно выборочно откатывать).

Если у тебя чот прям сложное - то дай коммитам имена (refs, ветки т.е) и пользуйся ими

А вообще interactive rebase и в частности для осьминогов --onto и --rebase-merges в помощь.
Однако если у вас слишком часто надо очень дофига мержить и ребейзить - то возможно есть смысл пересмотреть воркфлоу (= вы что-то делаете не так)/посмотреть на jujutsu (https://jj-vcs.github.io/jj/latest/), который сложные операции с историей реализует приятнее

> А вообще interactive rebase и в частности для осьминогов --onto и --rebase-merges в помощь.

Сколько сУрьёзных слов. А мог бы просто папочки в 7z создать.

Зато ты как кексперт странно как-то жьопу рьвёшь за откровенно мусорный оверинжиниринговый продукт. Уж не "специалист по гиту" ты на отдельной ставке?

> Зато ты как кексперт странно как-то жьопу рьвёшь за откровенно мусорный оверинжиниринговый
> продукт. Уж не "специалист по гиту" ты на отдельной ставке?

git юзаю в повседневной работе и для личных проектов, ты так говоришь будто тебе каждый день надо дёргать git rerere (https://git-scm.com/book/en/v2/Git-Tools-Rerere) и прочее

Чтобы научиться им пользоваться достаточно для написания патчей в linux тебе потребуется часа 2 времени, потом ещё 4 часа для уже более сложных вещей вроде rebase и прочего

Пользоваться linux на профессиональном уровне и считать что для гита требуются некие специалисты это параноидальная шизофрения, иди лечись

Но другие свободные альтернативы распределённых VCS загнулись.

CVS был топчик!

Отвратительным он был. Вздохнул с облегчением после перехода на гит.

Единственным адекватным был. Хотя и тоже оверинжиниринг.

Нет. "Адекватным" CVS был разве что по сравнению с ужасами типа Microsoft Source Safe. SVN уже был значительно лучше CVS. А Git гораздо лучше SVN.

Адекватным по сравнению с чем?
С "Новая Папка 38"?

RCS был топчик, после него смузихлебы одолели индустрию.

> RCS был топчик, после него смузихлебы одолели индустрию.

Это следствие охомячивания отрасли. Сейчас куда не плюнь — все программисты. И у 99% из них нет STEM-образования (а часто вообще никакой вышки нет).

Неиронично, но для совсем мелких или даже средних, банальное версионирование аля новая_папка2 внезапно неплохо справляется с задачей. Подход очень простой, старые версии архивируются, изменения в коде можно подписывать в отдельном файле.

От всей души надеюсь, что это сарказм

Все он верно пишет. Для каждой задачи свой инструмент. Если это простой не еоммандный проект, создать новую папку будет проще и быстрее.

Разве что на хелловрот с тремя файлами, иначе даже в личных проектах образуется достаточно кода чтобы за ним надо было нормально следить

> Разве что на хелловрот с тремя файлами

Судя по характеру комментариев, это твой максимум -- писать раздутые hello world. Хотя вроде ты и не индус, чтобы платили за количество строк кода. Подозрительно 🤔

обычно маленькие дети начинают копировать каталоги и создавать архивы, пока ещё боятся VCS. потом приходит понимание, что даже для хелловротов git init - первое, что нужно сделать

Тля, в Спарте вас бы со скалы ...

Запоминай или прямо копи-пЭйсти:

mkdir Суперпрога
cd Суперпрога
git init
cat <<EOF >CoC.md
Rust has a safe mem0ry management! Nyaaaaaaa!!!
EOF
git add --all
git commit -m "Суперпрога B0rnCry!"
git status
git log

И всё - ты уже белый человек, а не тварь дрожащая :-))))))

> От всей души надеюсь, что это сарказм

Если хоть раз приходилось сталкиваться с инфраструктурой не-айти компаний, где сайт и всё прочее делал племянник начальника - то можно понять что скорее всего не сарказм.

Увы, но эффект Даннинга-Крюгера сильно распространён

Да все уже поняли, что ты вахтер, любящий раздувать щеки, но по факту не написавший ни одного проекта.

+1. Например, Mercurial(Hg). Ума не приложу, каким надо быть дилетантом, чтобы выбирать Git! Самое кривое поделие со времён "линукса-ядра".

Git - де-факто стандарт в индустрии разработки ПО. Его используют не дилетанты, а профессионалы. А ты просто унылый хейтер-неасилятор.

> Его используют не дилетанты, а профессионалы

Да уж... По работе регулярно наблюдаю, как с ним мучаются даже гуру Git'а

Ну, значит не такие уж они и гуру

> Например, Mercurial(Hg)

Один нюанс(С) - может ты и не заметил, но он немножечко сдох(С) :(
Не пережил переезд пыхтона с 2-ки на 3-ку ...

Скоро гит по количеству строк кода догонит ядро линукса

Если в гите завёлся раст - точно догонит.

В меркуриале завелся ещё раньше

https://www.mercurial-scm.org/help/topics/rust

А если этого не случится, ты извинишься за свою неправоту?

Так первая версия линух имела лишь ~10200 строк кода, думаю гит уже давно обогнал его ;)

Слишком сложно и нагроможденно все становится. Скоро раздуют IT-пузырь до того, что понадобится отдельный специалист по git.

> Скоро раздуют IT-пузырь до того, что понадобится отдельный специалист по git.

Да нет, вместо gitops-инженера будет вайбgit.

Смешно будет, когда всех этих "инженеров" с гуманитарным образованием попрут, когда пузырь лопнет.

По факту, так и есть. НИ ОДИН юзер гита не скажет "Я знаю весь гит" - ибо нереально. Что говорит о непомерной раздутости инструмента ради местечковых бонусов. Не говоря уже о том, что никто не смог заюзать гит без месяцев тренировки и ГУЯ. В противовес Hg, который прозрачен как логическая цепочка Сократа.

> никто не смог заюзать гит без месяцев тренировки и ГУЯ.

Вызывающее неверная информация. Если ты на это не способен - говори за себя, только и всего.

А ты все ключи ls наизусть знаешь? Или ls - тоже "непомерно раздутый инструмент"?

> По факту, так и есть. НИ ОДИН юзер гита не скажет "Я
> знаю весь гит" - ибо нереально. Что говорит о непомерной раздутости
> инструмента ради местечковых бонусов.

Это всего лишь говорит о том, что инструментом можно пользоваться не залазя под капот.

Не думаю что там нужны месяцы тренировок. В основном несколько основных комманд для создания коммитов, веток, мерджей, и возможно реверта коммитов. Историю же и вправду проще просматривать через гуи, но не более того. Очень просто инструмент на самом деле

Врешь. Огромное количество народу пользуется гитом из консоли, потому что типовые сценарии требуют знания только git merge, git rebase, git add, git pull, git push, git checkout, git branch.
Единственное, что неудобно делать из консоли - это конфликты решать, это удобно в GUI делать графическом, с цветовой раскраской блоков.

Гит нужен исключительно для командной работы над очень крупными проектами на тысячи строк. Для всего остального быстрее и проще создавать новые папки. А теперь докажите, что это не проще. И я серьёзно.

> на тысячи строк

может на сотню тысяч?

Тысячи строк - это так-то и 2000 и 10000, что на крупный проект как-то не тянет.

Для меня даже одна тысяча это очень много. Мои проекты (торговые боты для Polymarket) укладываются обычно в сотню. Максимум две сотни строк. Возможно потому, что я практикую подход к написанию кода от suckless.org.

Короче пишешь питон скриптики на один файл, зачем маскировать это под какой-то мистический подход к написанию кода

Да и вообще питон скриптики на один файл легко 10к строк набирают за вечер, если есть, что писать. Вот работать с ними ад во всех отношениях -- даже редактор неимоверно лагает.

> один файл легко 10к строк набирают за вечер,

Обычно так комментируют те, кто вообще ни одной строки не написал.

>> один файл легко 10к строк набирают за вечер,
> Обычно так комментируют те, кто вообще ни одной строки не написал.

Чепуха, навалить под 10к строк питона не проблема за день. Разгребать ещё неделю придётся конечно.

Для начала попробуй 10к строк текста набить и оцени насколько это нереально в контексте кода.

> Для начала попробуй 10к строк текста набить и оцени насколько это нереально
> в контексте кода.

Текст сложнее кода, сразу скажу. А уж минимально осмысленный текст действительно не реально.

> Для меня даже одна тысяча это очень много.

Ты что, порядочный говн0кодер просто обязан на каждый пуK создавать классы и 100500 проверок обернутых в контейнер на докере с клиент-серверной архитектурой.

>> на тысячи строк
> может на сотню тысяч?
> Тысячи строк - это так-то и 2000 и 10000, что на крупный
> проект как-то не тянет.

Вижу в твои словах попытку возвысить себя над окружающими, но сработало это в обратную сторону. Ведь чем больше строк в твоём коде, тем этот код ХУЖЕ. Любой инженер скажет, что вероятность ошибки/неисправности возрастает с количеством точек отказа, ну т.е. в твоём случае строк кода :-)

> Вижу в твои словах попытку возвысить себя над окружающими, но сработало это
> в обратную сторону. Ведь чем больше строк в твоём коде, тем
> этот код ХУЖЕ. Любой инженер скажет, что вероятность ошибки/неисправности возрастает с
> количеством точек отказа, ну т.е. в твоём случае строк кода :-)

Вот, кстати, именно так рассуждают люди, не имеющие ни одного продукта за плечами. Любой продукт это минимум сотни тысяч строк. А средняя частота ошибок значение плюс-минус константное, но зависит от сложности (и всратости) логики, и никак не от количества строк.

> сотни тысяч строк

Эмм… Ты вообще осознаешь какой это объем текста? Ты столько простого человекочитаемого текста за всю жизнь вряд ли напишешь, не говоря про код.

Ты когда-нибудь видел полноценные продукты? Средний программист пишет от 1 до 10 тысяч строк кода в день, какой это объём? Ерунда. Написать не проблема, сопровождать (рефакторить, дорабатывать, искать ошибки) -- проблема.

8 часов рабочий день * 60 минут в часе * 60 секунд в минуте = 12000
твой программер пишет почти строку кода за секунду?

Ну почему, если писать 1 строку кода в секунду, за 8 часов получится 30000. И это значение "до", от в таком случае получится 3000. Но, чтобы написать за 8 часов то, что пишется менее чем за час, что-то должно быть не в порядке с "программером". Либо всё время уходит на отладку, покрытие тестами и документаций и так далее -- переключение между задачами тоже отнимает ресурсы. Но и в таком случае придётся потратить минимум половину оставшегося время на чаепития и беседы.

Если с гитом умеешь работать, то мысли использовать копии директории даже не возникает

> Если с гитом умеешь работать, то мысли использовать копии директории даже не
> возникает

А если не умеешь и не собираешься работать в команде, то и учить не стоит, забивая голову всем подряд, но только не кодом. Да.

Для такого случая гуй придумали.

Всё равно создавать папки быстрее, чем работать с гуем гита. Просто потому что это забивание гвоздей микроскопом.

Если ты работаешь 1 -- просто не публикуешь, гит всё ещё идеальный способ отслеживать историю. Он позволяет проследить логику изменений, что недоступно с копиями дерева файлов. А вот это действительно ценно. Если, конечно, не пихать всё в 1 коммит (осуждающе смотрю на разработчиков кед). Всё базовое взаимодействие с гитом досконально изучается за вечер, было бы там что учить.

1 коммит тоже зависит от контекста. Сделать один скваш из десяток  мусорных изменений, в единый информативный коммит - что такого плохого?

> 1 коммит тоже зависит от контекста. Сделать один скваш из десяток  
> мусорных изменений, в единый информативный коммит - что такого плохого?

Коммиты должны быть такими, чтобы их можно было идентифицировать и откатить при необходимости в последствии. И не тратить кучу времени на идентификацию всех зависимых изменений в десятках коммитов и ручное удаление.

Для этого и нужен сквош. Да и то не всегда помогает.

> А если не умеешь и не собираешься работать в команде, то и учить не стоит, забивая голову всем подряд, но только не кодом. Да.

Нет.

Если ты многократно вносишь изменения в свой скриптик на сотню строк, то git незаменим. Такого рода скриптики имеют тенденцию быть заточенными под слишком узкий случай, и их иногда приходится править, чтобы они справились с чуть-чуть другим случаем. Некоторые правки делаются для того, чтобы прогнать скрипт один раз, и откатить правки. Некоторые остаются навсегда.

git позволяет это упорядочить. Когда ты разглядываешь строчку кода, которая в последний раз менялась пять лет назад, и понять не можешь каким местом ты думал, когда её менял и нагромождал такое, то история git тебе напомнит о каком-то особом случае, из-за которого пришлось так извращаться. Когда ты столкнулся со специальным случаем, который требует правок, и ты помнишь, что сталкивался с чем-то подобным, ты можешь порыться по другим веткам, и найти тот подобный случай. Этого ты можешь достичь при помощи директорий, но сколько директорий ты будешь хранить? И не запутаешься ли в них потом? git это упорядочивает, позволяя скрыть с глаз долой ненужное, и в то же время присобачивать коммент к каждому изменению.

Это работает не только со скриптиками, это работает ещё и с конфигами. Я /etc дома держу в git, потому что я вношу туда изменения, и потом через 10 лет я не помню зачем они там. Или я помню, что проблема, которая мне досаждает меня сейчас, уже вылезала у меня и я её как-то исправлял, после обширного гугленья. И что, я опять сейчас полезу гуглить? Нет, я пороюсь в истории git.

> не собираешься работать в команде, то и учить не стоит

Если не собираешься работать в команде, то имеет смысл тем не менее посмотреть на инструменты, которые в команде используются, и разобраться как они используются. Они могут оказаться полезными.

Если ты не собираешься профессионально заниматься ремонтом квартир, то ты можешь обойтись без перфоратора. Дырки в стенах можно делать при помощи молотка и зубила. Но, если научиться пользоваться перфоратором, то сделать дырку под картину, которой можно закрыть большую дырку в обоях, будет гораздо проще.

Возникает, если у тебя бинарные данные или нужно бок о бок смотреть 2 версии проекта.

> Возникает, если у тебя бинарные данные или нужно бок о бок смотреть
> 2 версии проекта.

Для бинарных данных можно хоть свой мерждрайвер сделать (это не сложно, + есть готовые даже для libreoffice)/хоть smudge фильтр для преобразования их в не-бинарные для работы с ними как с текстом/хоть git annex для автоматического сохранения/выгрузки в/из S3 и работы с ним как с ссылокой/хоть git LFS для опять же хранения его как ссылки

Бок о бок ты в гите можешь сравнить хоть 10 версий проекта, все инструменты для этого есть, можешь даже для каких-то инструментов сделать несколько рабочих деревьев через git worktree

>> Возникает, если у тебя бинарные данные или нужно бок о бок смотреть
>> 2 версии проекта.
> git annex для автоматического сохранения/выгрузки в/из S3

Хочу локально хранить.

> Хочу локально хранить.

Ну вот LFS, я ж его тоже упомянул

Создать проще, только вот спустя время разбираться в этом зоопарке папок будет куда сложнее.

> Создать проще, только вот спустя время разбираться в этом зоопарке папок будет
> куда сложнее.

Удалить все старое, оставив последний вариант. Зачем хранить все? Никогда гитом не пользовался для личных проектов.

> Никогда гитом не пользовался для личных проектов.

это вообще не повод для гордости. когда (желаю тебе таки "когда", а не "если") начнёшь - тебе будет стыдно, что в принципе вслух такие глупости говорил

гит корявый беспорно, но более лучшего у нас ничего пока нет

Ну нет. Даже если у тебя ДВА разраба на 1 проект, всё равно нужна DVCS (Mercurial). Потому что не всегда ты заливаешь "готовый код" - иногда у тебя сделано пол-фичи, но нужно "залить на сервер", т.к. у тебя ноут сдыхает! Сделал бранч и заливай хоть вирусы.
Собственно, "бранчи" и есть краеугольный камень любой VCS - они позволяют всем залить свой кусок кода, но не портить "главный проект".

> Гит нужен исключительно для командной работы над очень крупными проектами на тысячи строк.

Тысячи строк - это "очень крупный проект"? По мне, так это очень мелкий проект.

> По мне, так это очень мелкий проект.

Так говорить может только тот, кто не осилил даже тысячу строк простого текста, не говоря о коде и программировании.

Так говорить может только тот, кто только и может, что строить предположения, кто и что может говорить. А сделать что-то реальное вместо своей болтовни не способен.

Ну и разве это не bloat?

> Ну и разве это не bloat?

Сферический в вакууме. Да. Он самый. Совсем скоро в это недоразумение будет вбухано человекочасов большая чем в само ядро :-)

Сабж — классический хрестоматийный пример оверинжиниринга.

> Сабж — классический хрестоматийный пример оверинжиниринга.

Хрестоматийный пример нинужного.

Не-не... архитектура там как раз простая (хоть и кривая), тут наглядный пример overbloated code. Overengineering - это когда print "hello world" решается через фабрики классов, DI и с тысячей тестов. :)

1. В целом git закончен, так что даже фиксация версии не должна ничего сломать.
2. Есть got.