The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Доступна система управления исходными текстами Git 2.41

02.06.2023 10:54

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

По сравнению с прошлым выпуском в новую версию принято 542 изменения, подготовленные при участии 95 разработчиков, из которых 29 впервые приняли участие в разработке. Основные новшества:

  • Улучшена обработка недостижимых объектов (unreachable), на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги). Недостижимые объекты удаляются сборщиком мусора, но до удаления определённое время остаются в репозитории для исключения состояний гонки. Для отслеживания периода нахождения недостижимых объектов необходима привязка к ним меток с временем изменения подобных объектов, что не позволяет хранить их в одном pack-файле, в котором все объекты имеют общее время изменения. Ранее каждый недостижимый объект сохранялся в отдельном файле, что приводило к проблемам при наличии большого числа свежих недостижимых объектов, ещё не подпадающих под удаление. В новом выпуске для упаковки недостижимых объектов по умолчанию задействован механизм "cruft packs", позволяющий хранить все недостижимые объекты в одном pack-файле, а данные о времени модификации каждого объекта отражать в отдельной таблице, хранимой в файле с расширением ".mtimes" и связываемой при помощи индексного файла с расширением ".idx".
  • Включено по умолчанию ведение на диске обратного индекса (revindex) для pack-файлов. При тестировании на репозитории torvalds/linux применение обратного индекса позволило ускорить ресурсоёмкие операции "git push" в 1.49 раза, а простые операции, такие как вычисление размера одного объекта при помощи "git cat-file --batch='%(objectsize:disk)'" в 77 раз. Файлы (".rev") с обратным индексом будут сохранены внутри репозитория в каталоге ".git/objects/pack".

    Напомним, что Git хранит все данные в форме объектов, которые размещаются в отдельных файлах. Для повышения эффективности работы с репозиторием объекты дополнительно помещаются в pack-файлы, в которых информация представлена в форме потока из объектов, следующих друг за другом (аналогичный формат используется при передаче объектов командами git fetch и git push). Для каждого pack-файла создаётся индексный файл (.idx), позволяющий по идентификатору объекта очень быстро определить смещение в pack-файле, по которому хранится данный объект.

    Включённый в новом выпуске обратный индекс нацелен на оптимизацию процесса определения идентификатора объекта по информации о размещении объекта в pack-файле. Ранее такое преобразование выполнялось на лету во время разбора pack-файла и хранилось только в памяти, что не позволяло повторно использовать подобные индексы и вынуждало генерировать индекс каждый раз. Операция построения индекса сводится к построению массива из пар "объект-позиция" и его сортировке по позиции, что может занимать много времени для больших pack-файлов.

    Например, операция вывода содержимого объектов, в которой используется прямой индекс, выполнялась в 62 раза быстрее, чем операция показа размера объектов, для которой данные о связи позиции с объектом не индексировались. После использования обратного индекса указанные операции стали занимать примерно одинаковое время. Обратные индексы также позволяют ускорить операции отправки объектов при выполнении команд fetch и push за счёт прямой передачи уже готовых данных с диска.

  • В протокол "credential helper", применяемый для передачи учётных данных при обращения к репозиторям c ограниченным доступом, добавлена поддержка передачи заголовков WWW-Authenticate между обработчиком учётных данных и сервисом, в котором производится аутентификация. Поддержка заголовка WWW-Authenticate позволяет передавать scope-параметры OAuth для более гранулированного разделения доступа пользователя к репозиториям и разграничения областей, доступных для запросов.
  • В команду for-each-ref добавлена опция форматирования "%(ahead-behind:<base>)", позволяющая разом получить сведения о числе коммитов, присутствующих или отсутствующих в определённой ветке, относительно другой ветки (на сколько одна ветка отстаёт или опережает другую на уровне коммитов). Ранее для получения подобной информации требовалось выполнить две отдельные команды: "git rev-list --count main..my-feature" для получения числа уникальных для ветки коммитов и "git rev-list --count my-feature..main" для получения числа отсутствующих коммитов. Теперь подобные вычисления можно свести к одной команде, что упрощает написание обработчиков и сокращает время выполнения. Например для показа не прошедших слияния веток и оценки отставания или опережения их основной ветки можно использовать однострочник:
    
    
       $ git for-each-ref --no-merged=origin/HEAD \
         --format='%(refname:short) %(ahead-behind:origin/HEAD)' \
         refs/heads/tb/ | column -t
    
       tb/cruft-extra-tips 2 96
       tb/for-each-ref--exclude 16 96
       tb/roaring-bitmaps 47 3
    
    вместо ранее применявшегося скрипта, который выполняется в 17 раз медленнее:
    
       $ git for-each-ref --format='%(refname:short)' --no-merged=origin/HEAD \
         refs/heads/tb |
         while read ref
         do
           ahead="$(git rev-list --count origin/HEAD..$ref)"
           behind="$(git rev-list --count $ref..origin/HEAD)"
           printf "%s %d %d\n" "$ref" "$ahead" "$behind"
         done | column -t
    
       tb/cruft-extra-tips 2 96
       tb/for-each-ref--exclude 16 96
       tb/roaring-bitmaps 47 3
    
  • В команду "git fetch" добавлена опция "--porcelain", при указании которой формируется вывод в формате "<flag> <old-object-id> <new-object-id> <local-reference>", менее читаемый, но более удобный для разбора в скриптах.
  • Добавлена настройка "fetch.hideRefs", позволяющая ускорить операции "git fetch" за счёт скрытия части ссылок в локальном репозитории на стадии проверки отправки сервером полного набора объектов, что позволяет сэкономить время, ограничив проверку только серверов, с которых напрямую извлекаются данные. Например, при проведении теста на системе с репозиториями, содержащими большое число отслеживаемых внешних ссылок, исключение всех ссылок, кроме адресованных целевому серверу $remote, позволило сократить выполнение операции "git fetch" с 20 минут до 30 секунд.
    
       $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \
       fetch $remote
    
  • В команде "git fsck" реализована возможность проверки повреждений, соответствия контрольных сумм и корректности значений в битовых картах доступности и обратных индексах.
  • В команде "git clone --local" реализован вывод ошибки при попытке копирования из репозитория, содержащего символические ссылки внутри $GIT_DIR.


  1. Главная ссылка к новости (https://www.spinics.net/lists/...)
  2. OpenNews: Уязвимости в Git, позволяющие перезаписать файлы или выполнить свой код
  3. OpenNews: Выпуск системы управления исходными текстами Git 2.40
  4. OpenNews: Уязвимости в Git, приводящие к утечке и перезаписи данных
  5. OpenNews: Выпуск git-совместимой системы управления версиями Got 0.80
  6. OpenNews: Две уязвимости в Git, способные привести к удалённому выполнению кода
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59234-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (152) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 11:15, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    542 изменения, что они там делают ваще?
     
     
  • 2.3, Аноним (3), 11:19, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    коммитят
     
  • 2.4, Аноним (4), 11:29, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а сколько должно было быть? точное число назови
     
     
  • 3.7, 1 (??), 12:14, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    42 же !
     
  • 3.8, Аноним (8), 12:15, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    тебе же написали 2.41
     
  • 2.84, Аноним (84), 08:04, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/git/git/compare/v2.40.0..v2.41.0
     

  • 1.5, Аноним (5), 11:40, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как в конфиге прибить для форспушей обязательное выполнение --force-with-lease и --force-if-includes ?
     
     
  • 2.15, Пряник (?), 13:02, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Альясом в bash или в самом Git (да, в нём тоже альясы есть в config).
     

  • 1.10, Аноним (10), 12:50, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    после svn на git без слёз не взглянешь. но да, миллионы мух не могут ошибаться
     
     
  • 2.12, Аноним (4), 12:57, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Subversion — свободная централизованная
    > централизованная

    И сразу фтопку.

    > миллионы мух не могут ошибаться

    Не будь как все. Ешь ногами, а код набирай носом.

     
     
  • 3.13, Аноним (10), 12:59, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    у тебя все репы централизованные на твоём гитхабе или гитлабе, а про децентрализованные фишки все забыли ещё до твоего рождения
     
     
  • 4.18, Аноним (4), 13:19, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > у тебя все репы централизованные на твоём гитхабе или гитлабе

    Нет, у меня все репы децентрализованные, потому что это гит. Особенно это пригодилось на работе, когда переезжали с публичного инстанса гитлаба на self-hosted: во время переходного периода были две одновременно каноничные, но разные по своему составу репы.

     
     
  • 5.27, lizard (??), 16:34, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Subversion умеет прозрачное зеркалирование сервера, переезд очень легкий: 'svn relocate' :)
     
     
  • 6.127, Аноним (-), 21:54, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В git вообще понятие переезда не имеет смысла - моя репа не хуже серверной Если... большой текст свёрнут, показать
     
  • 5.46, Аноним (46), 18:52, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    и где тут децентрализация? может ты толковым словарём не овладел?
     
  • 4.25, Аноним (25), 15:11, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    От наличия основного репозитория децентрализованные фишки никуда не исчезают. Например, турнут тебя с гитхаба - пушнешь на гитлаб и продолжишь работать как ни в чём не бывало. А репозиторий subversion, из которой VCS как из гoвна поля, ты в этом случае потеряешь. Ну и потом, децентрализованная VCS это не только децентрализованная разработка. subversion, в которой нельзя сделать локальную ветку без write доступа в основной репозиторий, вообще VCS считаться не может.
     
     
  • 5.26, Ананий (?), 15:49, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Например, турнут тебя с гитхаба

    не жалко отдавать хоть сколь-нибудь коммерческое поделие микрософту|${companyname} на съеденье?

    В случае селфхостед твоя проблема решается копированием репы. Или бекупы гиту не нужны?

     
     
  • 6.69, Аноним (69), 00:27, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > не жалко отдавать хоть сколь-нибудь коммерческое поделие микрософту|${companyname} на съеденье?

    О чём ты?

    > В случае селфхостед твоя проблема решается копированием репы.

    Какая проблема?

    > Или бекупы гиту не нужны?

    Иди проспись.

     
  • 6.128, Аноним (-), 21:55, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае селфхостед твоя проблема решается копированием репы. Или бекупы гиту не
    > нужны?

    YOLO, в случае гита каждая репа у каждого разработчика сама по себе - бэкап.

     
  • 5.28, lizard (??), 16:36, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Subversion умеет удаленный бакап нужных веток: svnrdump. А потом можно все отправить на новый сервер.
     
     
  • 6.72, Аноним (69), 00:36, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    - Вы пробовали им дампить и заливать репозиторий хотя бы в 200k коммитов Попроб... большой текст свёрнут, показать
     
     
  • 7.80, lizard (??), 02:58, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    200000 нет, но 20000 работает, хотя и далеко не мгновенно. Руками качать нет необходимости - все делает скрипт.
    > О бэкапе нужно заранеее позаботиться. Никто этого не делает.

    Сервер требует бакап. В том числе и git. Точка.
    > в нормальных VCS не нужно заранее заботиться о бэкапах

    ??? - в гит нет гарантии того, что на разных серверах хранятся полностью идентичные данные, нет гарантии одинаковой истории изменений. Так что бакап это необходимость всегда
    > что произойдёт в svn мире если вдруг народ после проблем с репозиторием не договорился и поднял НЕСКОЛЬКО его копий

    Такого быть не может при централизованной модели. Если у вас базар - svn не для вас, добро пожаловать в git, hg и т.п. Можно хоть патчи по почте посылать. Инструмент зависит от модели использования

     
     
  • 8.100, Электрон (?), 01:14, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В git есть абсолютная гарантия неизменности истории и содержания, потому что он ... текст свёрнут, показать
     
     
  • 9.101, lizard (??), 02:13, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    git init echo Бла бла бла хелло мир file1 txt git add file1 txt git commit -m ... текст свёрнут, показать
     
     
  • 10.121, Аноним (-), 21:23, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы прикалываетесь Ну вот вам на основе именно ваших потуг code cat 123 sh ... большой текст свёрнут, показать
     
     
  • 11.141, lizard (??), 02:15, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    нет, вы похоже не совсем понимаете о чем шла речь в примере... текст свёрнут, показать
     
     
  • 12.142, Аноним (142), 11:37, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    О том что вы картинно прострелили сами себе пятку и принялись вопить ... текст свёрнут, показать
     
  • 10.134, Электрон (?), 13:02, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пример хороший, но для другого После прочтения всё становится на свои места ht... текст свёрнут, показать
     
     
  • 11.140, lizard (??), 02:13, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ага - в гите вообще нет файлов и путей как сущности ... текст свёрнут, показать
     
     
  • 12.145, Аноним (142), 12:05, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что к лучшему - не брыкается при рефакторах кода Но чтобы это знать надо уметь ... текст свёрнут, показать
     
  • 5.39, FSA (??), 18:10, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Например, турнут тебя с гитхаба - пушнешь на гитлаб и продолжишь работать как ни в чём не бывало.

    Так можно сразу на Github, Gitlab, Bitbucket, gitflic какой-нибудь даже, и себе на сервер заливать постоянно. Везде дубликаты исходников. Турнули с одного, у тебя есть исходники на других. Останется самое сложное, организовать работу в новой системе. Но это сложно, если ты не один с репозиторием работаешь.

     
     
  • 6.67, Электрон (?), 23:30, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Где сложно? Мейнтейнеру хоть мылом пачти присылают. Он после мерджа распушивает ветки на все remote одной командой: git push  kuda nado. Откройте для себя несколько URL за одним remote. Любой другой после этого может откуда угодно клонировать. Принимать PR-MR - да, либо привязка, сторонний сервис или (как уже сказал) рассылка.
     
     
  • 7.129, Аноним (-), 21:56, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Более того - даже если на того майнтайнера или тот сервер упал автобус, или что там, кто угодно может перезалить реп куда ему угодно и подхватить разработку.
     
  • 5.120, lizard (??), 20:30, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В svn есть shelving - локальное хранилище, данные из которого не шлются на сервер при коммите. Удобно кесли нужно отложить работу не доделав коммит и переключиться на что-то другое. Или инет если пропал. Так что есть, хотя и в рудиментарной форме (но это центрадлизованная система в ней не должно быть ничего только локального)
     
  • 4.102, Аноним (-), 05:13, 04/06/2023 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 4.117, Брат Анон (ok), 08:20, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты путаешь гит с гитхабом/гитлабом. Первое -- распределённая система управления версиями. Второе -- надстройки над гитом.
     
  • 3.29, lizard (??), 16:58, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Централизованная система управления версиями имеет множество своих важных плюшек... большой текст свёрнут, показать
     
     
  • 4.37, Серб (ok), 18:02, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Например контроль доступа: есть гарантия, что важная ветка не расползется на 100500 репозиториев.

    Про git-svn слышал?

     
     
  • 5.55, Другой Аноним (?), 20:50, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошая вещь, но не в тему сказана. Как git-svn гарантирует, что важная ветка не расползется на 100500 репозиториев? Как git-svn даст доступ к коду без svn клиента?
     
     
  • 6.87, Аноним (87), 10:06, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю, просто наличие git-svn приводит к тому, что нет никаких гарантий, на то что код
    из svn репозитория не расползется на сотни, веток в разных репозиториях.

    Он просто опроверг высказывание.

     
     
  • 7.103, lizard (??), 08:33, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю, просто наличие git-svn приводит к тому, что нет никаких
    > гарантий, на то что код
    > из svn репозитория не расползется на сотни, веток в разных репозиториях.
    > Он просто опроверг высказывание.

    Нет, не опроверг. Если у юзера git-svn нет доступа к ветке, то ниткакой git-svn не поможет его получить. Если у юзера super-git-svn-etc есть доступ к ветка, то он может хоть копипастой в текст файл его утащить. Вопрос не в тулзе, а в наличии центрального контроля доступа

     
     
  • 8.106, Аноним (106), 10:30, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если у пользователя нет доступа - чем это отличается от git Если и там нет дост... текст свёрнут, показать
     
     
  • 9.107, lizard (??), 22:00, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    В git нет никакого контроля доступа Совсем На сервере он делается через костыл... текст свёрнут, показать
     
     
  • 10.108, lizard (??), 22:03, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И в svn контроли гранулированный - хоть к отдельной подветке ... текст свёрнут, показать
     
     
  • 11.109, lizard (??), 22:08, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Из гитхабчика регулярно утекают приватные ключи из открытых реп Жесть В svn ри... текст свёрнут, показать
     
     
  • 12.122, Аноним (122), 21:29, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Если разработчик д бил и заливает ключи в репу - кто ему доктор Тело пускающее ... текст свёрнут, показать
     
     
  • 13.139, lizard (??), 02:09, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тело не должно вообще морочиться Морочиться должен администратор сервера svn -... текст свёрнут, показать
     
     
  • 14.143, Аноним (142), 11:39, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Администратор сервера 1 на всю толпу и вообще не обязан знать за вообще всех как... текст свёрнут, показать
     
     
  • 15.155, lizard (??), 00:43, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, для корпораций, с тенденцией к по возможности максимальному контролю Вы ко... текст свёрнут, показать
     
  • 5.73, lizard (??), 00:39, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    git-svn это просто интерфейс к git, позволяющий использовать сервер svn. Вещь иногда очень полезная, неплохая, но иногда несколько глюбкавая.
     
     
  • 6.123, Аноним (122), 21:30, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > git-svn это просто интерфейс к git, позволяющий использовать сервер svn. Вещь иногда
    > очень полезная, неплохая, но иногда несколько глюбкавая.

    Он нужен 1 раз в жизни - получить нормальное представление репы из свина. Потом про него можно забыть навсегда.

     
  • 4.47, Аноним (46), 18:54, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как только ты прописываешь адрес сервака, уже идёт централизация. Нет никаких децентрализованных систем, это бредни.
     
     
  • 5.76, fuggy (ok), 01:01, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет гит не так устроен. Не обязательно прописывать сервер. Я могу прописать адрес Васяна, Васян адрес Стасяна, Стасян адрес Димана, Диман адрес Торвальдса. Где децентрализованный сервер? Это обычный p2p.
     
  • 5.88, Аноним (5), 10:07, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А если три сервера прописал, то центр где?
     
  • 5.124, Аноним (122), 21:32, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Как только ты прописываешь адрес сервака, уже идёт централизация.
    > Нет никаких децентрализованных систем, это бредни.

    А если я патчи в PACK файл перекидываемый между юзерами флопинетом оформил, центр тогда что? Да, получатель может сделать pull и из вот такого pack с патчами.

    Ну или вот локальное репо - у него вообще НИКАКИХ серверов не прописано. Даже локалхостовых. И?

     
  • 3.36, Советский инженер и пенсионер (?), 17:50, 02/06/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 2.14, Пряник (?), 13:00, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гит всего лишь реализация механизма. Что-то типа виртуальных снапшотов поверх контентно-адресуемой файловой системы. Есть ещё Mercurial и BitKeeper, которые делают то же самое. Не могу сравнивать с SVN, я вообще не понимаю зачем кому-то возможность быстро создавать и удалять ветки?
     
     
  • 3.16, Аноним (10), 13:02, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    git всего лишь NIH-синдром в самом существе, который стал популярным по тем же причинам, что и cmake, - чем фиговее, тем лучше
     
     
  • 4.65, Аноним (25), 22:03, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Бездоказательное утверждение Да, и git и cmake не идеальны, но а Они на голову... большой текст свёрнут, показать
     
  • 4.93, Аноним (93), 19:09, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, в этом что-то есть.
    По тому сколько изменений в git программу вносится, в структуру файлов-данных, и всё больше и больше каких-то очень специфичных опций и команд добавляется - превращается в какой-то комбайн.
    И в комбайн что-то превратить на самом деле не так сложно, гораздо сложнее продумать программу так, чтобы она и очень простой была и выполняла при этом все необходимые функции.
     
  • 4.97, Аноним (97), 21:17, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Руки прочь от CMake. Пока ваш базель/мезон не реализует всю функциональность симейка, хотя бы основную и многими используюмую, такую как поиск зависимостей и пакетирование, вам бы в тряпочку молчать, а не хлам бесполезный рекламировать, который для сборок софта НЕ во flatpakе/snap/Docker малопригоден.
     
  • 3.56, Аноним (56), 20:52, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >Гит всего лишь реализация механизма. Что-то типа виртуальных снапшотов поверх контентно-адресуемой файловой системы.

    А где другие имплементации этих снапшотов? Нет их, поэтому говорить о них как об отдельном продукте бессмысленно. Mercurial и BitKeeper не используют код Git.

     
  • 2.24, Аноним (25), 15:04, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смотри-ка муха считает что права именно она, а не остальные мухи.
     
  • 2.31, lizard (??), 17:16, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сравните CVE для git и svn: Для git репортов намного больше плюс полно количество arbitrary code execution. Для svn большинство серьезного - denial of service.
     
     
  • 3.32, soarin (ok), 17:20, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Security by Joe.
     
     
  • 4.33, Аноним (33), 17:43, 02/06/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 2.38, Аноним (38), 18:03, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > после svn на git без слёз не взглянешь. но да, миллионы мух не могут ошибаться

    А чего не CVS? 🤡

     
     
  • 3.61, Аноним (56), 21:05, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А почему бы и нет? Стабильная и быстрая штука.
     
  • 2.50, Аноним (50), 19:35, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А после RCS и Новая папка (212) вообще рыдаешь сутки не останавливаясь?
     
  • 2.68, мимо (?), 23:48, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Hello, this is Linus Torvalds and I pronounce SVN as GIT.
     

     ....большая нить свёрнута, показать (61)

  • 1.11, Пряник (?), 12:52, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Пишут гит, чтобы писать гит. Пока писали, стал тормозить, стали еще больше писать гит, стало еще больше тормозить...
     
  • 1.23, Аноним (23), 14:31, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Скоро эта утилита, предназначенная для менеджмента исходников ядра Linux, станет сложнее этого самого ядра.
     
     
  • 2.30, lizard (??), 17:03, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    чтобы пользоваться (черной магией) git пишут толстые книги. Но все равно юзеры регулярно портят свои репы (rebase хаха). При этом репу svn нельзя испортить - svn намного более безопасен (для малокомпетентного юзера)ю
     
     
  • 3.42, FSA (??), 18:31, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > svn намного более безопасен (для малокомпетентного юзера)

    Так эти юзеры удалённый репозиторий не испортят в таком случае. А у себя пусть ломают что хотят. Это их проблема, что они свою работу потеряют. Я правильно понял, что вы отсутствие потенциально опасной операции, которая в умелых руках позволяет исправить ошибки, представляете как преимущество?

     
     
  • 4.71, lizard (??), 00:34, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это преимущество в умелых руках. Но проблема в том, что некоторые юзеры любят лазить по разным stackoverflow и копипастить git команды не ситая сопроводительный текст. С фатальными последствиями, потому что в git локальный репо это король. В svn так не прокатит. Там сервер правитель всего.
     
     
  • 5.125, Аноним (-), 21:40, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > это король. В svn так не прокатит. Там сервер правитель всего.

    Ну и за одно вот это вот svn должен умереть. Задача VCS помогать разработке а не создавать проблемы и ставить палки в колеса разработчику.

    Git продолжает работать независимо от состояния сервера, наличия интернета и причуд апстрима. И, главное, мотается по версиям со скоростью ракеты. Что для VCS - must have.

    SVN вечно брыкается - то интернета нет, то сервер дурит, то DNS что-то не то вернул, то еще какая-то лабуда. А вот именно версиями он рулит крайне позорно и медленно, перекачивая на каждый пшит половину репы. Ну и зачем это недоразумение надо?! Ублажать каких-то маразматиков с синдромом собак на сене? Это ортогонально современным и эффективным процессам разработки.

     
  • 4.81, lizard (??), 03:01, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно испортить удаленный сервер --force готово
     
     
  • 5.105, Аноним (106), 10:27, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Поумалчанию установленный сервер - нет. Для этого еще в настройках сервера надо разрешить.
     
  • 2.35, Советский инженер и пенсионер (?), 17:47, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там один лишь официальный мануал тянет на трёхтомник ландсберга. Даже не представляю как это всё можно держать в голове, попутно программируя и используя ещё 100500 смежных технологий.
     
     
  • 3.43, FSA (??), 18:34, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А там всё и не надо держать. По большому счёту для повседневной работы хватает push, pull, status, add, commit, log. Может ещё что-то забыл. Всё остальное гуглится в течении минуты, если оно понадобилось.
     
     
  • 4.57, Аноним (56), 20:54, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Может тогда вообще использовать не Git, а другую систему попроще?
     
     
  • 5.59, FSA (??), 20:58, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Может тогда вообще использовать не Git, а другую систему попроще?

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

     
     
  • 6.62, Аноним (56), 21:08, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Напоминает C++
     
     
  • 7.64, FSA (??), 21:37, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Напоминает C++

    ¯\_(ツ)_/¯

    Я даже не знаю что тут ответить...

     
  • 6.110, lizard (??), 22:20, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    git изначальтно спроектирован кое-как для довольно извратного workflow (патчи от кого попало на мыло) с целью облегчить работу МАЙНТЕЙНЕРА (а НЕ разработчика). Поэтому черная магия git требуется регулярно. Люди страдают.
     
     
  • 7.111, lizard (??), 22:26, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сравните git и любые другие системы контроля версий - svn один бинарный файл, hg один бинарный файл. git - 100500 файлов и скриптиков на баше. Видно, что разработчику было интересно делать ядро. А тузу для версий он склепал тяп-ляп на коленке лишь бы работало. А оно внезапно взлетело :) И теперь все с эттим маются.
     
     
  • 8.130, Аноним (130), 22:21, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это как Сервак на котором svn крутится явно не 1 файл А без этого сервака оно ... большой текст свёрнут, показать
     
  • 8.131, Аноним (131), 23:16, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сервак svn точно в 1 файл не влезет, без сервака клиент - вообще ни о чем Он са... большой текст свёрнут, показать
     
     
  • 9.137, lizard (??), 02:03, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Пользуйтесь чем вам удобно, никто не заставляет Но каша из баша показывает изна... текст свёрнут, показать
     
     
  • 10.144, Аноним (142), 11:56, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    что писавший его 1 умел в модуляризацию и субзадачи 2 знал где критично, на... текст свёрнут, показать
     
     
  • 11.157, lizard (??), 00:54, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    что писавший его думал в первую очередь об облегчении своего личного труда в ... текст свёрнут, показать
     
  • 9.138, lizard (??), 02:06, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    причем тут сервак Речь идет о клиенте Сервак это вообще отдельная вещь Попроб... текст свёрнут, показать
     
     
  • 10.147, Аноним (142), 12:11, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Git сам по себе изначально не клиент и не сервер, он VCS Симметричный и самодос... текст свёрнут, показать
     
     
  • 11.156, lizard (??), 00:49, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Строго говоря рн не vcs совсем, так как тут нет ни версий ни файлов git это сис... текст свёрнут, показать
     
  • 5.70, Аноним (50), 00:33, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Используй, кто ж тебе не даёт-то? Как существование Git тебе лично мешает пользоваться чем-то попроще?
     
  • 4.126, Аноним (-), 21:42, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > А там всё и не надо держать. По большому счёту для повседневной
    > работы хватает push, pull, status, add, commit, log. Может ещё что-то
    > забыл. Всё остальное гуглится в течении минуты, если оно понадобилось.

    Ну например merge, на случай если ты все же сводишь в репу потенциально конфликтующие комиты эн разработчиков, хоть кто-то 1 на толпу должен уметь такое если в тиме более 1 чела :)

     
  • 3.66, Аноним (25), 22:11, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Там один лишь официальный мануал тянет на трёхтомник ландсберга

    Чтобы работать не нужно не только читать его весь, но и читать его вообще. Для работы достаточно знать 4 слова - clone,commit,pull,push которые тебе уже известны по любой другой vcs. Даже ключей никаких не нужно. В man нужно смотреть только когда/если понабится что-то нетривиальное.

    > Даже не представляю как это всё можно держать в голове

    Действительно - двор подмести, да бухнуть после работы, ничего больше в голове держать не надо. А то напридумывали каких-то комплюцкеров.

     
  • 2.89, Вы забыли заполнить поле Name (?), 14:28, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Скоро эта утилита, предназначенная для менеджмента исходников ядра Linux, станет сложнее
    > этого самого ядра.

    https://www.opennet.dev/opennews/art.shtml?num=52355

     

     ....большая нить свёрнута, показать (26)

  • 1.34, Советский инженер и пенсионер (?), 17:44, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Не устану повторять, что гит не нужен. Это лишнее колесо в телеге. Намного быстрее, проще и понятнее жать в контекстном меню 7z -> архивировать.
     
     
  • 2.48, Аноним (46), 18:57, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не прав от слова совсем. И дело не в git или другой системе контроля версий. А в том, что ты в любой версии можешь быстро сравнить изменения с предыдущими версиями + узнать кто тот дятел, что всё сломал.
    По твоей системе, надо сперва всё распаковать... А если там гиги?
     
     
  • 3.58, Аноним (56), 20:58, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Какие гиги, там один helloworld.rs
     
  • 2.49, Аноним (2), 19:03, 02/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мде, в 2023-м не знать про мёрдж.
     
  • 2.82, lizard (??), 03:03, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, git очень даже нужен - для своей модели использования. Для всего другого - другие подходящие инструменты, иногда svn. Это просто инструмент, а не религия.
     
     
  • 3.91, пох. (?), 17:45, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет, git очень даже нужен - для своей модели использования.

    его модель использования - автоматизация работы одного очень странного чувака, требовавшего присылания ему патчей мэйлом и порезанных так чтоб в экран 80*25 влазило.

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

    > Для всего другого - другие подходящие инструменты, иногда svn. Это просто инструмент, а
    > не религия.

    это религия. Проблема в том что разработчики никаким другим инструментом пользоваться не умеют и учиться не хотят. Они на самом деле этим тоже пользоваться не умеют и "ой, как вернуть как было?!" - но постулат основан на вере и опровергнуть его невозможно.

     
     
  • 4.92, Аноним (50), 18:54, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А как же опенсорс, никто никому ничего не должен, захотел 8212 форкнул Не вы... большой текст свёрнут, показать
     
     
  • 5.95, пох. (?), 21:02, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    во-первых, поляна уже загажена - причем не по щиколотку, а аж по пояс форкнуть ... большой текст свёрнут, показать
     
  • 4.96, Аноним (96), 21:11, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У git есть TortoiseGit и GUI-клиенты и плагины для файловых менеджеров. У pijul - нет. У git есть GitHub. У pijul - нет. У git есть биндинги и либы. У pijul - нет. Пока кто-то всё это не сделает, а на pijul не перейду.
     
     
  • 5.112, lizard (??), 00:14, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Есть несколько альтернатив, если надо именно распределенную систему - см https://www.fossil-scm.org/. Но гитхабчика там конечно не будет...
     
     
  • 6.113, lizard (??), 00:22, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, будет - сделали автозеркалирование d git
     
     
  • 7.114, lizard (??), 00:26, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Хотя fossil практически сам себе гитхабчик. Все в одном бинаре - и версиии веб интерфейс, вики и т.п. вплоть до чатика. Суперкомбайн.
     
  • 5.118, пох. (?), 11:39, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > У git есть TortoiseGit и GUI-клиенты

    у hg, svn и (с определенными особенностями) перфорсы - тоже есть.

    Но ты как обычно выбрал самую васянскую поделку из всех васянских.

    > кто-то всё это не сделает, а на pijul не перейду.

    держи нас в курсе

     
     
  • 6.133, Аноним (133), 01:28, 06/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > у hg, svn и (с определенными особенностями) перфорсы - тоже есть.

    Удачи тебе в взаимодействиях. Хорошо когда проприетарщики на самоизоляцию уходят :)

     
  • 2.148, Аноним (142), 12:12, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > понятнее жать в контекстном меню 7z -> > архивировать.

    Не очень понимаю как при таком пускании пузырей программировать что-то получается. А git bisect средствами 7z интересно как выполняется? Я бы на это посмотрел! :)

     

  • 1.40, Аноним (40), 18:11, 02/06/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +3 +/
     

     ....ответы скрыты (7)

  • 1.63, Аноним (63), 21:24, 02/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что бы делать - лишь бы на SHA256 не переходить...
     
     
  • 2.86, Аноним (86), 09:48, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что бы делать - лишь бы ненужного не делать.
     

  • 1.94, Аноним (93), 19:14, 03/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Какие-то индексы, обратные индексы индексы - зачем это всё? Есть же базы данных, в них всё это давно уже есть и хорошо работает, зачем переизобретать?
     
     
  • 2.98, Аноним (2), 21:48, 03/06/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    тут главное побольше накоммитить и показать свою активность hr'у
     
  • 2.104, Аноним (106), 10:25, 04/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие-то индексы, обратные индексы индексы - зачем это всё? Есть же базы данных, в них всё это давно уже есть и хорошо работает, зачем переизобретать?

    Все дело в скорости работы. Часто используемые операции должны работать быстро. Редкоиспользуемые - приемлемое время. И дальше идет ручная балансировка необходимой от БД функциональности. Есть базы данных, которые могут разрешить сделать ручную балансировку необходимой функциональности?

     
  • 2.115, lizard (??), 00:29, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.fossil-scm.org/ - на SQLite. Все уже сделано до нас.
     
     
  • 3.119, Серб (ok), 17:18, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это там где, для того, что бы поправить историю, надо конвертировать репозиторий в git, поправить в git'е историю, и конвертировать обратно?
     
     
  • 4.135, lizard (??), 01:57, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    поправить историю? Это зачем и как, как в гите? с оторванными ветками? Во вменяемой системе контроля версий история изменений не может быть изменена, иначе уже это не система контроля версий. История изменений должна отражать реальные изменения, сделанные в процессе работы. В противном случае это не история, а а не фейк. Как у Оруэлла.История свята и священна :)
     
     
  • 5.136, lizard (??), 01:58, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    любое вмешательство в историю превращает ее в фейк
     
     
  • 6.150, Серб (ok), 13:03, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > любое вмешательство в историю превращает ее в фейк

    сама по себе история никому не нужна

    нужны понятные и обоснованные изменения

    Блуждания в поиске подходящей реализации оставьте у себя в локальной ветке

     
     
  • 7.151, lizard (??), 00:25, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    правильная история помогает найти сточник ошибок, регрессии и т.п. При редактировании истории в git можно получить некомпилируемые коммиты, оторванные ветки и подобные проблемы. Гит строго говоря вообще не система контроля версий. (Но эт о не значит что гит плох. Он имеет свои плюсы и минусы как и любой тул)
     
     
  • 8.152, lizard (??), 00:29, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    для этого нужно правильно и обоснованно работать нормально организовать свой wo... текст свёрнут, показать
     
     
  • 9.162, Серб (ok), 12:57, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы из тех, кто никогда не ошибается ... текст свёрнут, показать
     
     
  • 10.164, lizard (??), 16:59, 09/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Все ошибаются Ошибка это тоже часть истории Не нужно ее прятать... текст свёрнут, показать
     
     
  • 11.169, Серб (ok), 13:26, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем рецензенту продираться сквозь ошибки ... текст свёрнут, показать
     
  • 10.167, lizard (??), 20:27, 09/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    возможно в случае ошибки имеет смысл править сообщение коммита post hoc, для мар... текст свёрнут, показать
     
  • 8.163, Серб (ok), 13:33, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Именно при редактировании истории этот процесс становится на порядок проще реали... текст свёрнут, показать
     
  • 5.149, Серб (ok), 12:59, 07/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Допустим один из разработчиков внес в проект код украденный из другого проекта.

    Через 5-ть лет на вас подали в суд.

    Ваши действия?

     
     
  • 6.153, lizard (??), 00:30, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    в svn? 'svn rm' :)
     
     
  • 7.154, lizard (??), 00:32, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    'git rm'
     
  • 7.161, Серб (ok), 12:57, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > в svn? 'svn rm' :)

    История доступна. Код в истории доступен. Решения суда не выполнили.

     
     
  • 8.168, lizard (??), 12:08, 10/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Почему же Ветка удалена, в публичном доступе украденного кода нет В текущих ве... текст свёрнут, показать
     
     
  • 9.170, Серб (ok), 13:29, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Удалять ветку, которая давно уже вмержена в основную, ну, или, отребейзена Како... текст свёрнут, показать
     
  • 6.158, lizard (??), 11:13, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну от вам другой пример. Вя инженер делаете  NASAMS и через пять лет ракета взрывается на старте или летит в зад запускающему. Поднимаете код и видите что история гита отредактирована, ветка пропала, коммит с предполагаемой ошибкой испорчен в результате правки истории и не компилируется вообще. Зато история выглядит красиво и изменения (месседжи?) выглядят обоснованными. Кто сидеть-то будет?
     
     
  • 7.160, Серб (ok), 12:55, 08/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Во первых:

    Кто-нибудь, когда-нибудь сел?

    Во вторых:

    Два типа репозиториев - это вполне норма для корпораций:
    один публичный;
    другой непубличный;
    В публичном удаляется то, что нужно удалить по закону.

    В третьих:

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

    И вот такая история должна храниться.

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

     
     
  • 8.165, lizard (??), 20:14, 09/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    У вас всегда есть шанс Ну и про NASAMSы мы не знаем, все секретно Систематич... текст свёрнут, показать
     
  • 8.166, lizard (??), 20:19, 09/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и правьте историю в публичном репозитарии для красоты Или вообще выкладывай... текст свёрнут, показать
     
     
  • 9.171, Серб (ok), 13:33, 13/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Тут, очевидно, что разница глобальная Публичная история должна быть красивой б... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (25)

  • 1.116, Neon (??), 05:06, 05/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как то чересчур переусложнили систему. Хрень какая та стала
     
     
  • 2.132, Аноним (131), 23:18, 05/06/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Как то чересчур переусложнили систему. Хрень какая та стала

    Плохому танцору всегда что-то мешает.

     

  • 1.159, lizard (??), 11:41, 08/06/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >[оверквотинг удален]
    >
    > нет, потому что он сам закопался.
    >
    > Во-первых автор ядра покинул проект в первый же год его существования (и да, это большие боссы но они играли не за гит а за мертворожденный биткипер). С тех пор много казавшихся тривиальными вещей так и не были реализованы или реализованы криво.
    > Во-вторых был выбран фантастически неудачный язычок с отступами (внезапно, даже перл на котором все еще написаны отдельные куски гита жив и портирован на мильен платформ, а вот впихон2 - таки всьо)
    > В-третьих, гитхап и гитляп, да.
    >
    > Третий пункт не имел бы определяющего значения, если бы автор не повторил изначальную ошибку гита - отсутствие хотя бы номинальной авторизации и разделения пользователей из коробки. То что позволяло svn как быть самодостаточным, так и легко интегрироваться в системы контроля версий.
    >
    > P.S. еще вишенка на тортике - неудавшаяся попытка начать переписывать. Ну вы поняли, на чем и чем кончилось. А время шло...

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру