The OpenNET Project / Index page

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

Выпуск распределенной системы управления исходными текстами Git 2.25

14.01.2020 13:40

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

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

  • Приближается к стабилизации и полной готовности возможность частичного клонирования (partial clones), позволяющая переносить лишь часть данных и работать с неполной копией репозитория. При обычном клонировании из репозитория копируются все данные, включая каждую версию каждого файла из истории изменений. Для очень больших репозиториев копирование данных приводит к значительному увеличению трафика и дискового пространства, даже если разработчика интересует лишь подмножество файлов. Для упрощения получения только части рабочего дерева исходных текстов в новом выпуске предложена экспериментальная команда "sparse-checkout" и новая опция "--sparse" для команды "clone".

    Ранее процесс выборочного клонирования производился через задание фильтров для отсеивания лишнего контента и опции "--no-checkout" для отключения восполнения недостающих файлов. После этого, перед выполнением операции checkout, требовалось включить настройку core.sparseCheckout и определить в файле .git/info/sparse-checkout список шаблонов исключаемых путей. Например, для клонирования без блобов и запрета извлечения файлов из вложенных каталогов глубиной 2 и больше можно было выполнить:

    
       git clone --filter=blob:none --no-checkout /your/repository/here repo
       $ cd repo
       $ cat >.git/info/sparse-checkout <EOF
       /*
       !/*
       EOF
       $ git config core.sparseCheckout 1
       $ git checkout .
    

    Новая команда "git sparse-checkout" существенно упрощает работу и сводит процесс организации работы с неполным репозиторием к командам:

    
       git clone --filter=blob:none --sparse /your/repository/here repo
       git sparse-checkout set /path/to/check/out
    

    Команда sparse-checkout позволяет установить список путей для checkout (set) без ручной настройки .git/info/sparse-checkout, а также вывести текущий список путей (list) и включить или отключить частичные checkout (enable/disable).

    Для оптимизации работы с очень большими репозиториями и списками шаблонов предложена настройка "git config core.sparseCheckoutCone", ограничивающая допустимые шаблоны (вместо произвольных шаблонов .gitignore можно задать все ли пути и все ли файлы в заданном подкаталоге следует извлекать). Например, если в большом репозитории есть каталог "A/B/C" и вся работа сосредоточена в подкаталоге "C", то при включении режима sparseCheckoutCone команда "git sparse-checkout set A/B/C" извлечёт содержимое "C" полностью, но из "A" и "B" извлечёт только необходимые для работы с "C" части.

  • Из документации ("git rebase -h") удалены все упоминания опции "--preserve-merges", которая объявлена устаревшей и вместо неё для переноса набора коммитов следует использовать "git rebase --rebase-merges".
  • Для улучшения читаемости сообщений с патчами, отправляемыми в списки рассылки, добавлена опция "git format-patch --cover-from-description subject", при указании которой в качестве темы сопроводительного письма для набора патчей используется первый абзац из текста описания ветки.
  • Реализована поддержка совместного применения команды "git apply --3way" и настройки "merge.conflictStyle" ("git apply" теперь учитывает стиль описания конфликта из merge.conflictStyle при необходимости разрешения конфликта после попытки применения файла с патчем к репозиторию).
  • Код определения функций, используемый в таких операциях как "git diff/grep --show-function/--function-context", расширен поддержкой определения границ функций в программах на языке Elixir.
  • В "git add", "git commit", "git reset" и другие команды добавлена новая опция "--pathspec-from-file", дающая возможность загрузить список путей из файла или входного потока, вместо их перечисления в командной строке.
  • Решена проблема с определением переименований на уровне каталогов при записи коммитов. Определение не работало в случае перемещения содержимого подкаталога в корень репозитория.
  • Предложена начальная реализация переработанной команды "git add -i", позволяющей добавлять изменённое содержимое в интерактивном режиме, переписанная с Perl на Си. Ведётся аналогичная переработка команды "git add -p".
  • Проведён рефакторинг команды "git log --graph", формирующей ASCII-изображение графа с историей изменений в репозитории. Переработка позволила значительно улучшить и упростить вывод без искажения структуры истории, что, например, решило проблему с вылезанием рисунка за границу ширины строки терминала.
  • Опция "git log --format=..", позволяющая изменить формат вывода, расширена поддержкой флагов "l/L" для вывода только части email-адреса, указываемой перед символом "@" (например, полезно, когда у всех разработчиков все email в одном домене).
  • В команду "git submodule" добавлена подкоманда "set-url".
  • Тестовые наборы обновлены в рамках подготовки к переходу на алгоритм хэширования SHA-2 вместо SHA-1.


  1. Главная ссылка к новости (https://lkml.org/lkml/2020/1/1...)
  2. OpenNews: Обновление Git с устранением 8 уязвимостей
  3. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.24
  4. OpenNews: Для OpenBSD развивается новая git-совместимая система контроля версий Got
  5. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.22
  6. OpenNews: Зафиксирована атака вредоносных шифровальщиков на Git-репозитории
Лицензия: CC-BY
Тип: Программы
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (70) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:53, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    SVN в 100 раз
     
     
  • 2.8, Анонец (?), 14:56, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    чем гит
     
     
  • 3.13, Снайпе (?), 16:10, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что?
     
     
  • 4.15, Аноним (15), 16:33, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    SVN в 100 раз
     
     
  • 5.19, Аноним (19), 17:03, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Зато Git в 100 раз
     
     
  • 6.28, little Bobby tables (?), 17:32, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    тоже верно
    чем свн.
     
  • 4.23, Аноним (-), 17:19, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Что?

    Медленнее.

     
  • 2.16, eRIC (ok), 16:34, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    SVN является как раз таки централизованной системой отслеживания кода, когда как GIT децентрализованная
     
     
  • 3.17, конь в пальто (?), 16:45, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и чо?
     
     
  • 4.39, eRIC (ok), 22:03, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > и чо?

    ничего, идите в гугл кто сравнивает SVN vs GIT

     
     
  • 5.60, Ан оНим (?), 22:52, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Код SVN красивше чем
     
  • 3.18, A.Stahl (ok), 16:47, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +12 +/
    А у шара нет граней, тогда как у куба их целых 6.
     
     
  • 4.22, Попугай Кеша (?), 17:19, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Можно сказать, что у шара - бесконечное число граней )
     
  • 4.24, Аноним (-), 17:21, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А у шара нет граней

    Игроделы с этим тезисом мягко говоря не согласятся. Более того - у хорошего шара граней много.

     
     
  • 5.27, A.Stahl (ok), 17:27, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Игроделы намного умнее чем ты о них думаешь.


     
     
  • 6.46, Аноним (46), 06:24, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Те из них кто поумнее - не жалеет граней на шары :)
     
     
  • 7.51, Анонымоус (?), 07:08, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Больше граней -- легче катать.
     
     
  • 8.61, Ан оНим (?), 22:52, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Шары не катают ... текст свёрнут, показать
     
  • 7.71, Попугай Кеша (?), 16:30, 20/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Те из них кто поумнее - не жалеет граней на шары :)

    А потом - почему это игра тормозит на 16 Гб оперативы? )

     
  • 4.29, little Bobby tables (?), 17:33, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а ещё был случай идем в столовку талоны профилакта проедать а навстречу бабы с иняза
     

  • 1.2, Аноним (2), 13:55, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    l залипает?)
     
     
  • 2.6, Аноним (6), 14:10, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В том то и дело, что именно "sparseCheckoutCone", а не "sparseCheckoutClone"
     

  • 1.3, iCat (ok), 13:56, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    1 коммит с каждого разработчика при учёте, что работали 7 дней...
    Не густо... :)
     
     
  • 2.5, анонимус_потерял_свой_логин (?), 14:07, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    иди, да помоги им своими коммитами
     
     
  • 3.10, НяшМяш (ok), 15:16, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сложна, там на сях надо писать
     
     
  • 4.21, анонимус_потерял_свой_логин (?), 17:09, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну да, на опеннете-то писульки писать проще намного
     
  • 4.25, Аноним (-), 17:22, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сложна, там на сях надо писать

    Ну так поэтому оно и крутое - работает шустро, ведет себя логично. И вообще, на что способны вебмакаки можно посмотреть в каком-нибудь hg. Фич навалили гору, зато все работает как картонный макет какой-то.

     
     
  • 5.40, анонн (ok), 22:21, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А то, что оно еще пару лет назад было наполовину на шелле code cloc git-2 0 ... большой текст свёрнут, показать
     
     
  • 6.47, Аноним (46), 06:25, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кстати вебманки о себе напомнили в соседней новости. И таки очень предсказуемо напомнили: картина Репина "дохайповались".
     
  • 6.62, Ан оНим (?), 22:55, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Неважно, шелл не шелл.

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

     
     
  • 7.69, Аноним (-), 18:51, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно, плохим алгоритмом можно и хороший ЯП ушатать, но все же теория ничто без практики. А алгоритм ничто без качественной реализации. И вот тут уже ЯП полностью сбросить со счетов сложно. Ну вот есть у вас офигенный алгоритм допустим шифрования - но на бэйсике, блин. И чего? Сами перепишете на что там вам хотелось? В процессе влепите десяток новых вулнов, сами того не желая. Потому что специфичная область, без владения которой стандартными подходами - только дров наломать можно.
     
  • 4.32, Аноним (32), 18:41, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    перепиши на расте - это проста! )))
     

  • 1.4, X5asd (?), 13:56, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    а переход на следущую sha что? надоело чтоль?
     
     
  • 2.14, Alex (??), 16:20, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    коллизии (почти) научились подбирать
     

  • 1.7, Ivan_83 (ok), 14:35, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    "В команду "git submodule" добавлена подкоманда "set-url"" - наконец то!
     
  • 1.9, Аноним (9), 14:57, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями

    Не "одной из", а самой. По сути, на данный момент единственной.

     
     
  • 2.11, aa (?), 15:18, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    самой популярной - да
    по надежности и производительности возможно есть и лучше (пусть ими и пользуется 1 человек)
    и любителей subversion и mercurial пока еще достаточно, чтобы не говорить,что гит - единственная
     
     
  • 3.12, microsoft (?), 15:33, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > и любителей subversion и mercurial пока еще достаточно

    но для них нет нашей прекрасной gitfs! Поэтому по производительности они безнадежно в пролете.

     
     
  • 4.20, Аноним (19), 17:04, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты еще скажи VFS for Git.
     
  • 3.26, Аноним (-), 17:25, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > и любителей subversion и mercurial пока еще достаточно

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

     
     
  • 4.30, Аноним (30), 17:40, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    хм какой смысл менять инструмент, который всем устраивает и под который уже отл... большой текст свёрнут, показать
     
     
  • 5.31, Ordu (ok), 18:01, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не надо делать revert в таких случаях. revert ведь не удаляет коммит, а накладывает сверху ещё один, который обнуляет эффект первого.

    Делай git reset, чтобы поставиь HEAD на нужный коммит, таким образом ветка приходит в состояние, будто никакого коммита и не было вовсе. Или вообще ничего не делай: внеси исправления в issue, и вторым мергом исправь первый. История коммитов будет чуть более грязной, но ты потом можешь исправить это, когда будешь перекидывать её из issue в master. Правда для этого надо не merge делать, а rebase. Но я бы вообще рекомендовал rebase, merge принудительно сливает все коммиты в один, rebase же позволяет некоторые слить, некоторые оставить как есть, некоторые опустить вообще.

     
     
  • 6.33, Аноним (30), 18:51, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    я это уже понял но для меня было несколько неожиданно, что новый MR не будет со... большой текст свёрнут, показать
     
     
  • 7.35, Аноним (35), 18:58, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > а если после этого слияния прошли новые? не всегда же нужно именно "верхний" MR откатить...

    Просто для понимания: при откате неверхнего мержа могут и конфликты возникнуть, которые вам исправлять придётся. И результат исправления которых поломает и другие мержи.

     
  • 7.44, Ordu (ok), 02:31, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оглядываясь назад на свой опыт освоения git, я бы рекомендовал забить для начала... большой текст свёрнут, показать
     
  • 5.34, Аноним (35), 18:54, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сразу скажу, что практически не работал с гитлаб.

    > если же там будет несколько человек топтаться

    У нас в компании workflow реализован несколько по-иному, и за релиз-ветку всегда есть ответственный. Один. И только он может вливать в пререлизную/тестовую ветку задачные ветки. Соответственно, он в курсе всех ревертов и мерджей, и проблемы с топтанием нескольких человек не возникает.

    > всякие CI/CD научить откатывать изменения, ломающие ветки

    В таком случае разработчику issue должно уведомление слаться, что его ветку откатили, с номером реверта, чтобы при следующем MR он понимал, что в текущей testing его изменений нет и нужно ревертнуть автоматический реверт.

    Кроме того, вы ссылаетесь на конкретный workflow, и для вашей организации он просто может не подходить.

     
     
  • 6.36, Аноним (30), 19:03, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    интересно, где я спалился вроде ж не озвучивал, что именно с ним работаю а е... большой текст свёрнут, показать
     
     
  • 7.41, Аноним (41), 22:57, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Гит распределённый, у грамотных людей реквесты называются пулл-реквестами По... большой текст свёрнут, показать
     
     
  • 8.42, Аноним (41), 23:07, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Соврал, не на lkml это видел, а на kernel org Например https git kernel org... текст свёрнут, показать
     
  • 8.55, Аноним (30), 11:57, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо за ликбез увы, в наших реалиях документирование не работает документа... большой текст свёрнут, показать
     
     
  • 9.72, Попугай Кеша (?), 16:37, 20/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да бежать надо из компании, где все так быстро меняется Обычно это менеджеры ка... текст свёрнут, показать
     
  • 5.43, Alex (??), 01:53, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Merge не делается до проверки работоспособности, а если возникают проблемы, то да, revert/частичный откат изменений.

    Обычно flow выглядит так:

    * master/develop/release -- рабочее состояние, ничего не сломано, можно собрать/запустить
    * feature/my-cool-feature -- твоя ветка разработки, ты там делаешь все, что хочешь

    CI всегда собирает master. Остальные ветки по возможности (железо слабое, проект тяжелый и т.п.)

    Также всегда собираются и Pull Request'ы, но с оговоркой, что собирается не ветка, которую будут сливать, а merge commit -- по сути такое состояние репы, в котором твою ветку как бы слили в таргет-ветку (например, master). При таком подходе CI будет запускать сборку на новый коммит в PR-ветке, а также на новые коммиты в таргет-ветке (master).

    Если нужен rollback, в случае если, например, релиз не поднялся, то в гите ничего я бы не стал менять, а просто на почту/месенджеры информацию послал бы.

     
     
  • 6.57, Аноним (30), 12:35, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    каким образом это реализуется допустим, имеем такие ветки - master, testing, is... большой текст свёрнут, показать
     
     
  • 7.67, Аноним (67), 02:45, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Как мне получить состояние ветки testing после апрува MR для проверки работоспособности, не выполняя собственно MR?

    git checkout testing # или git switch по современному
    git merge --no-ff --no-commit issue2
    <проверка работоспособности> && git commit -m "I am the best." || echo "MR is BAD" | mail vasya

     
  • 5.48, Аноним (-), 06:41, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > который всем устраивает и под который уже отлажены все процессы?

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

    > Зато взамен вы получите... что?

    Нормальный инструмент от профессионалов и современные, эффективные workflow, например.

     
     
  • 6.59, Аноним (30), 12:48, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    подобного рода диалоги - неконструктивны у прогресса должна быть конкретная цел... большой текст свёрнут, показать
     
     
  • 7.68, Аноним (67), 03:57, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем вашей компании гит если svn вас устраивает?
    И Вам зачем? Чтоб не казаться ретроградом?

    > И диалог с людьми, которые имеют реальный опыт работы с git - это тот конструктив, за которым я сюда пришел.

    Однако приглашение к диалогу выглядит как "Ну поуговаривайте меня, поубеждайте перейти на GIT. А я буду говорить фууу, ваш GIT не решает наших проблем".

     
  • 7.70, Аноним (-), 19:07, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Несомненно А чем цель в виде современного эффективного воркфлоу плоха Посмотри... большой текст свёрнут, показать
     
  • 5.65, Аноним (65), 12:46, 17/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Подобные затруднения возникают когда не понимают не знают принципы работы инстру... большой текст свёрнут, показать
     

  • 1.37, Аноним (37), 19:25, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В subversion хотя бы удобнее хранить всякую мультимедию, где она централизовано хранится на сервере, есть svn lock и т.д. А git? Чтобы загрузить жалкий 14 Кбайтный xml файл нужно загрузить терабайт wav'ок. А в svn можно просто отдельные файлы загружать.
     
     
  • 2.45, Anonymqwe (?), 05:07, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Git LFS
     
  • 2.49, Аноним (-), 06:42, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > есть svn lock и т.д.

    А, чо, это они у TFS'а "фиче" научились? Так офигенно, когда дев {слинял в отпуск, заболел, уволился, забухал} и оставил половину репы залоченой. Так что потом все околачивают груши и ждут пока одмины сшибут лок :)

     

  • 1.38, Аноним (38), 20:39, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    С этой "partial clones" ещё работать и работать. До удобства и лёгкости SVN ещё далеко. Тут нельзя просто выкачать файлы из папки /A/B/C При таком частичном клонировании будет воссоздана структура вложенности каталогов что и даром не сдалось если человек хочет работать только с содержимым в папке C
     
     
  • 2.50, Аноним (-), 06:51, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Удобство и легкость svn можно понаблюдать, сделав чекаут проекта месячной давности и сравнив как это "быстро" и "удобно" качает все и вся.

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

     
  • 2.66, Аноним (67), 02:12, 18/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут нельзя просто выкачать файлы из папки /A/B/C

    И это хорошо сдерживает от превращения репозитория в файлопомойку.

    > если человек хочет работать только с содержимым в папке C

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

    А вообще, не нужно пытатся "прогнуться" под git.
    Выбирайте те средства (svn например), которые решают ваши проблемы, а не добавляют новые.

     

  • 1.52, Анатоним (?), 10:50, 15/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно просто, с философской точки зрения, в git есть репозиторий git?
     
     
  • 2.54, Аноним (32), 11:20, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    git лежит в репозитории git, ага, рекурсия - она такая!
     
  • 2.56, Andrey Mitrofanov_N0 (??), 12:32, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно просто, с философской точки зрения, в git есть репозиторий git?

    Ч-чё прям, как маленький-то?!  Микрософт Гитхабб заботится о Вас.


    [I]Git via Git

    If you already have Git installed, you can get the latest development version via Git itself:

    [CODE]  git clone https://github.com/git/git  [/CODE]
    [/I]-- https://git-scm.com/downloads

     

  • 1.53, Ананимас009 (?), 10:53, 15/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вброшу https://svnvsgit.com/
    Если со связью проблем не прдвидется и хотелось бы хранить бинарь с возможностью скачать именно содержимое директории n-го уровня в репозитории, то  svn гораздо удобнее?

    Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит и гитгм погоняет.

     
     
  • 2.58, Andrey Mitrofanov_N0 (??), 12:45, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вброшу
    > Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит
    > и гитгм погоняет.

    Никому верить нельзя, мне - можно.(ц)старина Мюллер

    [I]" and LLVM continue to use Subversion as the main version control system. "[/I]

      <=>

    http://www.phoronix.com/scan.php?page=news_item&px=LLVM-SVN-To-Git-Next-Week
      & https://lists.llvm.org/pipermail/llvm-dev/2019-October/136107.html

     

  • 1.63, Аноним (63), 02:14, 16/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    какой нафиг SHA-2?
    SHA-3 давно стандарт
     
  • 1.64, trolleybus (?), 09:30, 16/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > 2.25

    "Однако... Два двадцать пять!" (c) 12 стульев

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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