The OpenNET Project / Index page

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

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

20.10.2020 14:32

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

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

  • Включена экспериментальная возможность использования алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при записи объектов в репозиторий. Хэш формируется на основе содержимого каждого объекта в Git и является его уникальным идентификатором. Любое изменение данных или заголовков объекта приводит к изменению его идентификатора. Возникновения коллизий в алгоритме хэшировния теоретически не исключает формирование двух разных наборов данных, имеющих один результирующий хэш. При активности в пять миллионов коммитов в секунду вероятность возникновения естественной коллизии оценивается в 50% за 7 млрд лет.

    К сожалению алгоритм SHA-1 оказался не стойким к искусственному формированию коллизий, но совершение реальных атак по подмене объектов в Git через манипуляцию коллизиями SHA-1 маловероятно, так как для подмены отдельного объекта необходимо, чтобы подменяемый объект уже содержал шаблон коллизии, т.е. произвольный блок подменить не получится. Теоретически возможна лишь замена уже ранее добавленного атакующим блока, но она требует чтобы в изначально принятом в репозиторий вредоносном блоке присутствовал достаточно большой кусок бинарных данных, вызывающих коллизию, что при работе с кодом не останется незамеченным. Кроме того, каждый объект в Git содержит не только данные, но и служебный заголовок, содержимое которого не подконтрольно атакующему, но который участвует при вычислении проверочного хэша, что нарушает условия возникновения коллизии.

    Так как каждая коллизия требует огромных ресурсов для вычисления, уже вычисленные шаблоны, приводящие к коллизиям, известны и ранее в Git была добавлена проверка на попытки их использования в объектах. Теперь Git переходит на новый уровень защиты и намерен заменить алгоритм хэширования на более надёжный, что требует изменения формата объектов. Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256, так как SHA2 уже применяется в Git для цифровых подписей. Логика выбора в том, при использовании SHA-256 и SHA3-256 в коде Git, компрометация любого из них приведёт к проблемам с безопасностью, поэтому лучше зависеть от одного алгоритма, а не от двух. Кроме того, SHA-256 широко распространён и поддерживается во всех криптографических библиотеках, а также демонстрирует очень хорошую производительность.

    В Git 2.29 реализована возможность включения нового формата объектов при создании репозитория:

    
    
       $ git init --object-format=sha256 repo
       Initialized empty Git repository in /home/ttaylorr/repo/.git/
     
       $ cd repo
       $ echo 'Hello, SHA-256!' >README.md
       $ git add README.md
       $ git commit -m "README.md: initial commit"
       [master (root-commit) 6e92961] README.md: initial commit
        1 file changed, 1 insertion(+)
        create mode 100644 README.md
    
       $ git rev-parse HEAD
       6e929619da9d82c78dd854dfe237c61cbad9e95148c1849b1f96ada5ee800810
    

    На данном этапе разработки можно лишь выбрать между SHA-1 и SHA-256, но пока нельзя одновременно сочетать разные хэши в одном репозитории. Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256. В будущем планируют добавить возможности для обеспечения переносимости. В частности, будет добавлена возможность вычисления для записываемых объектов одновременно хэшей SHA-1 и SHA-256, с сохранением таблиц трансляции. Подобные таблицы трансляции позволят старым клиентам SHA-1 обращаться к репозиториям, использующим SHA-256, а после преобразования репозитория в SHA-256, дадут возможность продолжить обращения к коммитам по ссылкам с хэшами SHA-1.

  • В команды "git fetch" и "git push" добавлена поддержка исключающих спецификаций ссылок (refspec), расширяющих правила сопоставления ссылок между ветками в локальном и внешнем репозиториях. Исключающие спецификаций ссылок могут быть полезны в ситуациях, когда нужно не только выбрать, но и исключить некоторые ветки из сопоставления. Например, когда необходимо извлечь все ветки "refs/heads/*", кроме одной "refs/heads/ref-to-exclude", раньше требовалось указать полный список, явно включающих каждую ветку, для чего можно было использовать скрипты вида:
    
       $ git ls-remote origin 'refs/heads/*' |
         grep -v ref-to-exclude |
         awk '{ print $2:$2 }' |
         xargs git fetch origin
    

    В Git 2.29 появился оператор исключения "^". Выражения с данным оператором допускают шаблоны, но не могут ссылаться на идентификаторы объектов. Начинающиеся с "^" спецификации ссылок исключаются из сопоставления и рассматриваемый выше пример можно свести к команде:

    
       $ git fetch origin 'refs/heads/*:refs/heads/*' ^refs/heads/ref-to-exclude
    
    

    Исключающие спецификации ссылок также можно использовать в настройках:

    
       $ git config --add remote.origin.fetch ^refs/heads/foo
    
  • В "git shortlog" появилась возможность группировки коммитов по содержимому дополнительных полей, таких как "Reviewed-by:" и "Coauthored-by:", а не только по автору или коммиттеру ("git shortlog -c"). В Git 2.29 добавлена опция "--group", которая по умолчанию обеспечивает группировку по автору ("--group=author"), а также поддерживает группировку по коммиттеру ("--group=committer") и произвольным полям ("--group=trailer:поле"). Например, для вывода списка наиболее активной рецензирующих разработчиков можно указать:
    
       $ git shortlog -ns --group=trailer:reviewed-by v2.28.0.. | head -n5
        40  Eric Sunshine
        10  Taylor Blau
         4  brian m. carlson
         2  Elijah Newren
         1  Jeff King
    

    Допускается указание нескольких выражений "--group" при запуске и использование опции "--format" для изменения формата вывода. Например, для учёта соавторов или помощников в списке можно указать:

    
       $ git shortlog -ns --group=author --group=trailer:co-authored-by
       $ git shortlog --format="...helped %an on %as" --group=trailer:helped-by v2.28.0..v2.29.0
    
  • В "git for-each-ref" добавлены новые поля, которые можно указывать в опции "--format", помимо имени, типа и идентификатора объекта. Например, добавлены поля contents:size, subject:sanitize и модификатор :short для отображения коротких идентификаторов объектов. Также разрешено указание нескольких аргументов "--merged" и "--no-merged" для фильтрации ссылок.
  • При возникновении конфликта в процессе выполнения операции "git merge" заголовок сообщения о коммите теперь помещается в скобки для более явного отделения данных из коммита от диагностических сообщений Git.
  • Добавлена новая настройка "merge.renormalize", при установке которой операции сheck-out и check-in выполняются для каждой стадии трёхстороннего слияния.
  • Возвращена отключённая в выпуске Git 2.27 вторая версия коммуникационного протокола Git, который используется при удалённом подключении клиента к Git-серверу. Ошибка, приводившая к проблемам со стабильностью, диагностирована и устранена.
  • В команду "git bisect", используемую для выявления ревизии, в которой возникло регрессивное изменение, добавлена опция "--first-parent" для изменения отбора коммитов, проходящих между заведомо рабочей ревизией и ревизией в которой зафиксировано проявление проблемы. При указании "--first-parent" учитываются только коммиты в объединённой ветке, пропуская сам коммит на слияние.
  • Повышена эффективность работы внутренней команды "git index-pack", применяемой при выполнении "git push" или "git fetch", за счёт распараллеливания операций упаковки индекса на многоядерных системах.
  • Добавлена настройка "merge.suppressDest", управляющая добавлением фразы "into $dest" в сообщения "Merge $upstream into $dest", выдаваемые при слиянии веток (ранее, по умолчанию для основной ветки фраза "into $dest" не выводилась).
  • Устранена уязвимость в бэкенде "contrib/mw-to-git" (не собирается по умолчанию), предназначенном для помещения и извлечения данных из MediaWiki. Проблема позволяла организовать выполнение кода при обращении к экземпляру MediaWiki, находящемуся под контролем злоумышленника.


  1. Главная ссылка к новости (https://lkml.org/lkml/2020/10/...)
  2. OpenNews: Новая версия Git 2.28, позволяющая не использовать имя "master" для основных веток
  3. OpenNews: Предложен метод определения коллизий в SHA-1, пригодный для атаки на PGP
  4. OpenNews: Обновление Git с устранением ещё одной уязвимости
  5. OpenNews: Уязвимость в Git, приводящая к утечке учётных данных
  6. OpenNews: GitHub добавил защиту от атак, использующих коллизии SHA-1
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/53923-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (148) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 15:03, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Читая чейнджлоги, мне каждый раз мерещится, что git из простой булки белого (или черного) хлеба превращается в трамвай. Надеюсь просто мерещится.
     
     
  • 2.2, Аноним (2), 15:08, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +20 +/
    В какой момент git был простым? Довольно сложная VCS с момента рождения, просто он стал индустриальным стандартом.
     
     
  • 3.14, m.makhno (ok), 16:01, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сложный он ровно до того момента, пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил до этого знакового знакомства. Потом, правда, приходится разбираться ещё с трактовками его фич разномастными хостингами, с их модно-молодёжными workflow's.
     
     
     
    Часть нити удалена модератором

  • 5.24, Аноним (24), 16:46, 20/10/2020 [ответить]  
  • +8 +/
    Имеется в виду что сначала нужно освоить vi и emacs и тогда уже гит будет казаться простым.
     
  • 4.53, TheFotoMag (ok), 20:19, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил

    Бешено плюсую.

     
  • 4.93, Аноним (2), 11:36, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так про все что угодно можно сказать, haskel сложен пока не проникнешься его философией, многомерные пространства сложны пока не проникнешься их философией.

    Помню когда начал работать с git первые пол года перед каждым шагом делал tar czvf. До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитов, путаю git clean и git reset. Пользуюсь гит с 2012 года.

     
     
  • 5.98, Ordu (ok), 13:33, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если ты заглядываешь в заметки и не можешь запомнить команды не потому, что тебе... большой текст свёрнут, показать
     
     
  • 6.100, Аноним (2), 14:11, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как много текста ни о чем. У git сложный CLI. Чуть более предметно.

    Кейс 1:

    Я случайно закомител лишний файл, но еще не отправил коммит на удаленный репозитарий. Как мне убрать лишний файл из последнего коммита?

    Я могу только заглянуть в заметки и вытащить от туда команду: git reset 'HEAD@{1}', после которой я повторяю заново коммит без этого файла.

    Кейс 2:

    Я случайно добавил в индекс лишний файл, как его убрать из индекса не удалив. Я вот не помню, кажется через reset. Мне надо опять заглянуть в заметки.


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

    Так GIT стандарт, где не работал везде гит, я пользуюсь тем что есть.

     
     
  • 7.102, Аноним (2), 14:39, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну и раз я критикую, я хотел бы сказать какой CLI на мой взгляд был бы более понятным:

    git rm   удалить файл с диска
    git rmi  удалить файл из индекса
    git undo [N] - отменить последние N действий
    git squash N - объединить последние N коммитов в один.
    git squash 772e40f-fe89105 - объединить указанные коммиты в один.

     
     
  • 8.104, Ordu (ok), 15:58, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Напиши скрипт, проблем-то Эмм Это как В список отменяемых действий включать... текст свёрнут, показать
     
     
  • 9.106, Аноним (2), 16:16, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я и пользуюсь rebase, в vi меняю строчки на squash нужных мне коммитов, только д... текст свёрнут, показать
     
     
  • 10.112, Ordu (ok), 16:58, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Прикинь, я впервые вижу команду git rebase --interactive HEAD N Я даже не уве... большой текст свёрнут, показать
     
     
  • 11.122, Аноним (2), 19:52, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А можно знать три аккорда и играть боем Использую как terminal multiplexer, на... большой текст свёрнут, показать
     
     
  • 12.123, Аноним (2), 19:56, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я вспомнил какой был svn workflow git stash git pull git pop - резолвинг конф... текст свёрнут, показать
     
     
  • 13.125, Ordu (ok), 21:06, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ууу Откуда вы такой взяли Какой-то гений придумал, а вы потом мучались ... текст свёрнут, показать
     
     
  • 14.128, Аноним (2), 22:45, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Коллективно придумали за один день, в первый день был только один вопрос, как св... текст свёрнут, показать
     
  • 12.124, Ordu (ok), 21:01, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Один член тут моторные навыки Надо пальцами попадать по ладам в нужных местах, ... большой текст свёрнут, показать
     
     
  • 13.127, Аноним (2), 22:21, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почти так и было, лично мне тогда git был не нужен, svn хватало Я надеялся что ... текст свёрнут, показать
     
     
  • 14.129, Ordu (ok), 22:50, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри Ты ... большой текст свёрнут, показать
     
     
  • 15.130, Аноним (2), 23:09, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Моя психика мне говорит что мне было тогда не интересно и до сих пор не интересн... текст свёрнут, показать
     
  • 7.103, Ordu (ok), 15:56, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.
    > Так GIT стандарт, где не работал везде гит, я пользуюсь тем что
    > есть.

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

     
     
  • 8.105, Аноним (2), 16:06, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Рекомендуете начать с аутотренинга перед зеркалом ... текст свёрнут, показать
     
     
  • 9.107, Ordu (ok), 16:17, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это уж кому что помогает ... текст свёрнут, показать
     
  • 7.115, all_glory_to_the_hypnotoad (ok), 18:16, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Все твои кейсы делает, очевидно, git reset git reset --hard HEAD 1 Опция --har... большой текст свёрнут, показать
     
  • 7.121, Аноним (2), 19:07, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати я тут ошибся указав git reset 'HEAD@{1}', в моих заметках сказано что это делает UNDO для UNDO, видно из-за простоты git этого никто пока не заметил.

    А UNDO коммита как написал товарищ выше: git reset --soft HEAD~

    Прямо очень интуитивно, я как вижу git reset --soft HEAD~ так сразу понимаю что это откатывает коммит, проще пареной репы.

     
  • 3.26, all_glory_to_the_hypnotoad (ok), 16:50, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это абсолютная чушь, Git простой как топор. Проще SVN, HG и многих других VCS. Потому у меня обратный вопрос - почему важные архитектурные изменения (развитие протокола, поддержка нескольких хешей и т.д.) происходят медленно, но коммитов стабильно не мало. Я, например, за 627 своих типичных изменений по объёму мог бы почти полностью переписать такой пакет и значительно доработать архитектурно.
     
     
  • 4.31, fossilscm (?), 17:22, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Это абсолютная чушь, Git простой как топор.

    Я не согласен!

     
     
  • 5.96, Аноним (2), 11:40, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда: Git прост как бензопила!
     
  • 4.33, an0nymous (?), 17:35, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Проще SVN, HG

    Какой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется.
    По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего и осозновал что делает) на порядки сложнее чем тот же hg. в нем много лишних абстракций торчат наружу, которые могли бы быть скрыты и интерфейс стал бы проще.

     
     
  • 5.89, пох. (?), 10:04, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    поскольку гит представляет собой не человеческую программу, исполняющую ровно од... большой текст свёрнут, показать
     
     
  • 6.97, anonymous yet another (?), 12:51, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы транслируете мнение совершенно не разбирающегося в архитектурах VCS. С желаниями от "configurations management" и игнорированием всего остального.
     
  • 5.101, all_glory_to_the_hypnotoad (ok), 14:29, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в Git примерно всего две простых абстракции - это ADG и индекс. В SVN одна простая с линеной историей, одна мозговыносящая связанная с ветками, тэгами и мержами директорий в директории (не видел как пользователи копируют trunk в NNN GiB в trunk?), и ещё некоторое кол-во поменьше. В Hg одних веток только несколько штук, в плане неконсистентности это самая yблюдочная VCS.

    Документации к Git больше если сравнивать c, например, svn, просто потому что в Git значильно больше функциональности. Однако это не означает что для работы нужно знать всё и всем пользоваться. Чтобы странный пользователь ничего плохого не делал есть прекоммитные хуки, причём ими пользуются во всех VCS для ограничения деятельности альтернативно одарённых персонажей.

     
  • 4.54, TheFotoMag (ok), 20:27, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Git простой как топор

    Судя по непрязни к Гиту — ни один его критик к разработке не имеет никакого отношения.

    Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут на порядок!!!

    Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана и уверены, что бабушкина пенсия растет на дереве.

    Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!

     
     
  • 5.55, TheFotoMag (ok), 20:30, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >> Git простой как топор
    > Судя по непрязни к Гиту — ни один его критик к разработке
    > не имеет никакого отношения.
    > Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут
    > на порядок!!!
    > Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана
    > и уверены, что бабушкина пенсия растет на дереве.
    > Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!

    Продолжая заочную дискуссию с безработными энтузиастами открытых решений — JIRA. Без нее тоже никак.

     
     
  • 6.81, nomad__ (ok), 07:49, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > JIRA. Без нее тоже никак

    очень даже как, потому что есть Redmine.

     
     
  • 7.135, TheFotoMag (ok), 09:56, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> очень даже как, потому что есть Redmine.

    Редкостная чушь сей Redmine

     
     
  • 8.136, nomad__ (ok), 10:04, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На вкус и цвет все люди разные По крайне мере, за него платить не надо ... текст свёрнут, показать
     
     
  • 9.137, TheFotoMag (ok), 14:12, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё как надо Каким это бесплатными образом вы намерены обеспечить группе до... текст свёрнут, показать
     
     
  • 10.138, nomad__ (ok), 14:14, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но за саму систему платить не надо, в отличие от Jira ... текст свёрнут, показать
     
     
  • 11.140, TheFotoMag (ok), 20:31, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А админить Пушкин будет Самому доки курить и ночей не спать 1 чел 40 тыщ А... текст свёрнут, показать
     
     
  • 12.141, nomad__ (ok), 05:43, 23/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я разраб, а не бизнесмен, в буй мне не впилась своя контора с ее гемором И да, ... текст свёрнут, показать
     
  • 6.88, Аноним (88), 09:57, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > JIRA. Без нее тоже никак.

    Редкое дерьмо.

     
  • 5.87, пох. (?), 09:53, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    утипупсичек, ну конечно же Все просто кроме тебя, вчерародившегося, тут есть е... большой текст свёрнут, показать
     
  • 4.75, GG (ok), 04:57, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну перепиши и доработай, все тебе будут благодарны и может даже денег отсыплют
     
  • 3.57, anonymous yet another (?), 20:44, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если тут есть люди, имеющие отношение к психологии или преподаванию (чего-либо, не важно) --- поясните, пожалуйста, вероятную мотивацию жмыхателей на значки +/- к комментариям 3.26 и 3.14. Спасибо.
     
     
  • 4.76, GG (ok), 04:58, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Увидели что там уже есть +/- и добавили свой чтобы не выделяться из толпы
     
     
  • 5.142, n242name (?), 20:17, 23/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вхуярил тебе минус, а у тебя стоял там плюс, наверное, доморощенный ты психолог, это потому что я хочу выделиться из толпы?

     
  • 4.145, n00by (ok), 08:47, 24/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В 3.26 -- за вводный негативный заряд "Это абсолютная чушь". Далее комментарий дельный, но не все дочитали.
    В 3.14 вывод в споре о вкусах навязывается заметно мягче ("Сложный он ровно до того момента, пока не проникнешься его философией"), но оратор напрасно попытался обобщить субъективный опыт. Люди разные, одним таблицу умножения проще зазубрить, другим каждый раз заново в уме столбиком складывать.
     
  • 3.80, nomad__ (ok), 07:48, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В какой момент git был простым? Довольно сложная VCS с момента рождения

    Это в каком же месте он сложный? Или не осилил https://git-scm.com/book/ru/v2?

     
  • 2.86, пох. (?), 09:45, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    конечно мерещится - он всегда был троллейбусом из буханки, причем с квадратными колесами. Как он может превратиться в трамвай?!

     

  • 1.3, Аноним (3), 15:12, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Хэши в постквантумную эпоху пострадают? А то планируют на 5 лет, а дальше хоть трава не расти.
     
     
  • 2.4, myhand (ok), 15:25, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Хэши в постквантумную эпоху пострадают?

    Вся современная криптография пострадает.  Факторизация со скоростью умножения - это вам не шутки!

    > А то планируют на 5 лет

    А вы уже запаслись пророчеством Нострадамуса когда она настанет, эпоха энта?  Отсыпите?

     
     
  • 3.19, Аноним (3), 16:23, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вон каждый день заявляют о квантум супремасэ, и вроде довольно близко продвинулись уже. Скоро придём к тому, что вся "криптография" будет на запутанных частицах (вроде там сбер что-то такое делал ГОДА 4 НАЗАД), где вмешательство будет исключено. Изначально выбрать sha1 было примерно как выбрать des, а теперь поменять на 3des,
     
     
  • 4.38, rshadow (ok), 18:12, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Еще далеко. Если корпорации и смогут, то ломать чужое это уголовка. Опасно для бизнеса. У спецслужб и так все есть. Надо ждать массовый сектор, а его пока в планах не видно.
     
     
  • 5.91, Аноним (91), 10:30, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > У спецслужб и так все есть

    ага, два раза есть.

    [sarcasm]

    и у сбера также

     
  • 5.132, Аноним (132), 07:05, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А обработка персональных данных без согласия - это что? Я вот банку передал давным давно бумагу, что отзываю согласие на обработку персональных данных, и требую произвести их уничтожение, а также всех их копий у всех контрагентов. И даже подписи работников банка на своём экземпляре вытребовал.

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

     
  • 4.67, Ivan_83 (ok), 00:14, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кавантовые компы угроза для ассимтричной крипты, но не для хэшей и симметричной крипты.
    Когда Линус начнал гит кажется sha2 ещё не было.
    sha2-256 ещё удобен тем что аппаратно есть в райзенах, впрочем sha1 тоже есть.
    А вот sha2-512 и sha3 аппратно пока нет.
     
  • 3.45, n00by (ok), 18:57, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Хэши в постквантумную эпоху пострадают?
    > Вся современная криптография пострадает.  Факторизация со скоростью умножения - это вам
    > не шутки!

    Факторизация чего? Вы типа думаете, что поля Галуа - это по которым гулял некий французский дяденька?

     
     
  • 4.78, myhand (ok), 06:46, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Факторизация чего?

    Больших целых.

     
     
  • 5.83, funny.falcon (?), 08:38, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А при чем тут SHA в любой ипостаси? Вы с RSA не перепутали?

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

     
     
  • 6.139, myhand (ok), 17:46, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А при чем тут SHA в любой ипостаси?

    При том. что алгоритм Гровера.  С SHA-2 тут, насколько я знаю, "все не так однозначно" (ц).

    > А для эллиптических кривых уже квантовые алгоритмы есть?

    В смысле?  Тут тот же алгоритм Шора может быть использован.

     
  • 6.143, n242name (?), 21:22, 23/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    насколько я курил вопрос - уже есть, однако появилась криптография на изогениях, но все в зародышевым состоянии
     
  • 2.35, Аноним (35), 18:06, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    не особо. Может быть, когда-нибудь придется увеличить размер хэша например до 384 бит, но придумывать новые алгоритмы нет нужды. От квантовых вычислений страдает только асимметричное шифрование
     
     
  • 3.48, Аноним (3), 19:27, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я слышал оценки в районе 4096 для RSA. И то, это скорее потому, что теоретическая база для эффективного квантового подбора таких ключей пока не существует.
     
  • 2.63, Аноним (132), 23:58, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Алгоритм Гровера только квадратичное ускорение даёт, по сравнению с экспоненциальным для Шора.
     

  • 1.5, б.б. (?), 15:25, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    о, крутая вещь. а есть hg-репозиторий, где можно его скачать?
     
     
  • 2.49, Michael Shigorin (ok), 19:43, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Могу дать вместе с unzip.arj. :)
     
     
  • 3.74, б.б. (?), 03:21, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    у меня есть ha.lha и lha.ha, оба смешные
     

  • 1.6, Аноним (6), 15:37, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    А я до сих пор пользуюсь SubVersion и всегда с улыбкой смотрю на очередные новости про гит и хг, и про ребейспроблемы
     
     
  • 2.8, Аноним (8), 15:44, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обычно с улыбкой смотрят на болванчиков которые без интернета не могут ни коммит, ни лог сделать, а чтобы переключиться на другую задачу им приходится изменённые файлы двигать. А на тех кто крупное изменение льёт одним коммитом, потому что rebase чтобы разбить его на топики не умеет, смотрят без улыбки и просто указывают им на дверь.
     
     
  • 3.11, Аноним (-), 15:46, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Какую дверь, что ты несешь такое вообще ?
     
     
  • 4.22, Аноним (8), 16:44, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На дверь из IT конторы очевидно, потому что профнепригодность.
     
     
  • 5.42, Козлетто (?), 18:47, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > На дверь из IT конторы очевидно, потому что профнепригодность.

    А у нас в ТИУ на "Информационные системы и технология" кроме меня даже о гите и краем уха не слыхали, а уж тем более о всяких rebase и СКВ вообще подавно.

     
     
  • 6.43, Козлетто (?), 18:47, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> На дверь из IT конторы очевидно, потому что профнепригодность.
    > А у нас в ТИУ на "Информационные системы и технология" кроме меня
    > даже о гите и краем уха не слыхали, а уж тем
    > более о всяких rebase и СКВ вообще подавно.

    И не только студенты, но и преподы

     
  • 5.46, Аноним (46), 19:00, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Смешно конечно такие писульки читать, профнепригодность из-за того что коммиты большие?

    Походу у вас какие-то спартанские порядки в конторе. Все пишут по-разному, в том числе и в опер сорсе коммиты в 2 десятка файлов иногда встречаются. Обычно это вопрос договорённости в команде.

    До сих пор смешно с такого детского максимализма, ну до поделать, хорошо что я не в такой команде)

     
     
  • 6.68, Аноним (8), 00:53, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    При чём тут максимализм? Факт 1 - есть code review. Факт 2 - мегакоммит невозможно качественно поревьюить. Поэтому в отличие от профпригодности ревьюера такой коммит либо идёт в прод непоревьюеным, либо заворачивается. В первом случае это рано или поздно ломает прод, во втором разработчик не выполняет свою прямую работу. В результате в обоих случаях отправляется в дворники. Ну либо учится git и rebase и делает ветки из маленьких, атомарных, легко обозримых коммитов.
     
     
  • 7.72, Crazy Alex (ok), 02:20, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Человек что-то лабает на коленке и что такое промышленное программирование не понимает. Бывает, убеждать бесполезно пока сам не побьётся.
     
  • 3.30, freehck (ok), 17:15, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ох уж это российская любовь к ребейзам. Чем вам просто мерджить-то не нравится? "Не аккуратненько"? =/
     
     
  • 4.59, anana (?), 20:57, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мёржи превращают историю в нечитабельное месиво.

    Ребейзы (при правильном использовании) делают красивую линеаризованную историю, где каждый коммит в истории на своём месте и сразу понятно что и когда кто делал (точнее заканчивал делать).

    Разумеется там где разработчики не пишут описания изменений и смешивают пачку несвязных изменений в один коммит - мёрж / не мёрж уже ничего не поменяет.

     
     
  • 5.79, Анатолий (??), 07:17, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    мержить можно и сквошем.
     
  • 5.92, freehck (ok), 11:27, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Мёржи превращают историю в нечитабельное месиво.

    Это не мёрджи. Это неотлаженный воркфлоу.

     
  • 4.69, Аноним (8), 00:56, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы вмержить ветку, её нужно сначала отребейзить (совершенно не обязательно на свежий master) и причесать - фиксы опечаток влить в те коммиты где опечатки были сделаны, большие коммиты разбить и т.д.
     
  • 3.62, Аноним (62), 23:57, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    За ребайсе надо сразу в торец
     
     
  • 4.70, Аноним (8), 01:00, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Такое говорили 15 лет назад неучи не видевшие и не хотевшие видеть нормальные VCS. Сейчас причесать ветку перед мержем - обязательное правило. Ребейз ветки на master (т.е. с перемещением корня) - дело вкуса, но по мне так нелинейная история допустима только в совсем маленьких проектах, иначе (когда есть > 5 параллельных ветвей) читать её невозможно.
     
  • 4.131, Аноним (131), 06:28, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В торец надо тем, кто отправляет на ревью всю свою помойку коммитов, образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты ошибки сделал в ходе работы и как их исправил. Его интересует конечный результат.
     
     
  • 5.134, пох. (?), 09:51, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    конечный результат в случае не двустрочного исправления он оценить не сможет в п... большой текст свёрнут, показать
     
  • 2.9, Аноним (-), 15:45, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и дурак.
     
  • 2.13, Аноним (13), 15:51, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    просто ты замшелый пенек. какой нахер subversion? брось уже каку!
     
  • 2.47, Аноним (47), 19:05, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Zip с циферками еще круче, его все даже github использует, аж скулы от улыбки сводит.
     
  • 2.50, Michael Shigorin (ok), 19:45, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ребейспроблемы

    А что именно Вы предпринимаете в svn, когда надо свести две своих ветки -- например, в основной были мелкие исправления, которые местами пересекаются с текущей разработкой (возможно, где-то и конфликтуют)?

    Я просто немного помню, как это выглядело с cvs.  С гитом это хотя бы проблемы (в переводе на русский -- задачи), и проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядом по локалке доступен.

     
     
  • 3.58, anonymous yet another (?), 20:56, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Без server-side (священо)действий --- никак. Лочим доступ (когда на запись, а когда и вообще) на час--день--неделю, сливаем backup в сторонку, говорим "ой, мама" и трудимся. После открытия доступа слушаем матюки и угрозы, вжимаем голову в плечи, лочим доступ и пытаемся поправить то, что наворотили. Иногда приходится повторять всё несколько раз. Но вера в святой backup нас поддерживает.
     
  • 3.90, пох. (?), 10:21, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    merge нужных изменений и - чем ТУТ поможет rebase Сломает ветку Спасибо, я об ... большой текст свёрнут, показать
     
  • 2.71, Аноним (8), 01:04, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy делает ни что иное как ребейз [этих изменений на новый head].
     
     
  • 3.94, пох. (?), 11:38, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это мерж И более того, явный мерж делается точно так же - через working copy Н... большой текст свёрнут, показать
     
     
  • 4.116, Аноним (8), 18:19, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-)

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

     
     
  • 5.119, пох. (?), 18:38, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё
    > изменение

    не может - оно где-то в origin/чтототам происходит в терминах гита.
    Твои комиты _никуда_ не денутся, и даже попортить автомагическим мержем НЕ закомиченое тебе не дадут. (Закомиченное - дадут, полагая что это именно то что ты хотел, но ты всегда можешь вернуть исходное состояние, это история.)

    А в svn/cvs ничего из этого нет, и для работы с _чужими_ проектами это действительно проблема.

    Подделка происходит при rebase. Поинтересуйся на досуге, что при этом на самом деле происходит с историей.

     
  • 5.133, пох. (?), 09:39, 22/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    есть нет Подделка - это именно подделка истории, когда изменения придуманные и... большой текст свёрнут, показать
     
  • 2.82, nomad__ (ok), 07:50, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ребейспроблемы

    например какие? А то вот уже 7 лет пользуюсь гитом и что-то не припомню проблем с rebase.
    Перешел, кстати, с svn.

     

  • 1.7, Аноним (-), 15:44, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Какой-то фольклер вместо вменяемого ченжлога, еще и испорчено корявым переводом.
     
  • 1.10, ALex_hha (ok), 15:45, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > А я до сих пор пользуюсь SubVersion

    сочувствую бро

    > и всегда с улыбкой смотрю

    те, кто работал с svn в цирке больше не смеются

    > и про ребейспроблемы

    в svn их просто нет. Нет человека - нет проблем ( с )

     
  • 1.12, Аноним (13), 15:46, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    дебильная логика. sha3 стандарт. не sha2, не sha1, не md5. sha3! нафига использовать старье?
     
     
  • 2.18, Anonymousqwe (?), 16:21, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И sha256 тоже стандарт, только предыдущий.
     
     
  • 3.25, Аноним (13), 16:50, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    те использоваться уже не должен ибо выявлены проблемы в sha1 и sha2. использовать нужно sha3
     
     
  • 4.36, Аноним (36), 18:10, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А ну-ка, на бис, какие ПРОБЛЕМЫ выявлены в SHA2?
     
     
  • 5.40, Аноним (13), 18:33, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    недостаточная стойкость к коллизиям очевидно
     
     
  • 6.84, funny.falcon (?), 08:48, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфлинк, пожалуйста.

    В SHA2 (а sha256 - это тоже sha2) пока что не найдено даже теоретических уязвимостей. SHA3 принимали не потому, что SHA2 был сломан, а потому, что SHA2 построен по принципу, похожему на SHA1 (который сейчас условно сломан). Опасаясь ВОЗМОЖНОГО ПОЯВЛЕНИЯ уязвимостей в SHA2, было решено принять параллельно стандарт SHA3, чтобы был алгоритм, не похожий на SHA2. Потому, кстати, победил Keccak, а не Blake/Blake2, которые в софтварной реализации заметно быстрее.

     
     
  • 7.114, Аноним (13), 17:15, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В марте 2008 года индийские исследователи Сомитра Кумар Санадия и Палаш Саркар опубликовали найденные ими коллизии для 22 итераций SHA-256 и SHA-512.В сентябре того же года они представили метод конструирования коллизий для усечённых вариантов SHA-2 (21 итерация). Позднее были найдены методы конструирования коллизий для 31 итерации SHA-256 и для 27 итераций SHA-512.
     
     
  • 8.149, microsoft (?), 02:48, 31/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас тебе скажут что это другое... текст свёрнут, показать
     
  • 3.34, кэп (?), 17:48, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > sha256 тоже стандарт

    нет, sha256 это sha2 с увеличеным размером хэша

     
  • 2.64, Аноним (132), 00:00, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это стандарт NiStA.
     

  • 1.16, Аноним (16), 16:18, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как бы это сделать pull не для текущей ветки, но и не переключаясь на ветку которую стягиваешь. Например чтобы посмотреть в ней что менялось и подмержить
     
     
  • 2.17, Аноним (13), 16:21, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    напиши скрипт который будет переключатся, делать pull и переключаться назад.
    а вообще fetch -a
     
     
  • 3.28, Аноним (16), 16:52, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как всегда всё гениальное просто... просто проскочило мимо меня) Спасибо
     
  • 2.20, Аноним (24), 16:42, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Через гитлаб например мышкой.
     
     
  • 3.21, Аноним (24), 16:43, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чушь написал. Думал речь про пулл реквест, а не пулл.
     
  • 2.29, all_glory_to_the_hypnotoad (ok), 16:57, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мб тебе нужен git fetch
     

  • 1.23, Аноним (24), 16:45, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >>Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256
    >>На данном этапе можно лишь выбрать между SHA-1 и SHA-256

    Так SHA2-256 или SHA-256 добавили? Или это одно и тоже?

     
     
  • 2.27, Аноним (13), 16:51, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    SHA-256 это SHA1-256
     
     
  • 3.37, Аноним (36), 18:11, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет.
     
  • 2.39, Аноним (36), 18:14, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Из педивикии:
    ===
    The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.
    ===
    SHA-224, 256 -- считаются 32-битными вордами, SHA-384, 512, 512/* -- 64битными.
    Кроме того, отличаются кажется IV (кому интересно точно, читайте педивикию и стандарты).

    И всё это -- семейство SHA-2

     

  • 1.32, Козлетто (?), 17:27, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде где есть часто изменяемые файлы и необходимость командной работе с ними. А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в этой помойке не разберёшь где что лежит
     
     
  • 2.41, JL2001 (ok), 18:35, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
    > где есть часто изменяемые файлы и необходимость командной работе с ними.
    > А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
    > этой помойке не разберёшь где что лежит

    потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы

    но я присоединяюсь к вашему недоумению

     
     
  • 3.44, Козлетто (?), 18:52, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
    >> где есть часто изменяемые файлы и необходимость командной работе с ними.
    >> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
    >> этой помойке не разберёшь где что лежит
    > потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
    > но я присоединяюсь к вашему недоумению

    А что мешает этом ворду или другой аналогичной программе использовать текстовый недеструктивный формат? Вендорлок?

     
     
  • 4.60, anonymous yet another (?), 21:11, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Микрософт ;)

    Вообще-то в MS Word есть встроенный контроль версий. Пригодность к использованию по назначению --- не знаю, я word'ом не пользуюсь. Судя по тому, что об этом почти никто не знает, наверное не пригодно. Там много чего интересного при желании можно найти. Я из присланной рекрутёрами описания вакансии ради интереса достал оттуда: компанию, запостившую вакансию, дату когда её создали, имена hr-ов в оригинальной компании и рекрутинговом агенстве, имя заинтересованного руководителя, примерное количество соискателей на эту вакансию и динамику изменений требований к кандидату, включая денежное довольствие (откуда следовало, что с наймом на эту позицию проблемы).

     
     
  • 5.73, Crazy Alex (ok), 02:27, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вполне пригодно и активно используется. В либре аналогичное есть. Проблема скорее в том, что общая культура работы с данными в ворде в среднем по больнице чудовищна - ну там, на одного учёного тысяча секретарш, которые даже стили не понимают.
     
     
  • 6.77, GG (ok), 05:02, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У учёных тоже каша в головах.
    То ли дело писатели, вот у этих гит хорошо заходит.
     
  • 6.108, anonymous yet another (?), 16:40, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Беда в том, что чувствительная информация регулярно утекает незаметно для потребителя. И сделано так (по крайней мере, было; есть ли сейчас?) "из коробки".
     
  • 3.61, fuggy (ok), 21:15, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На самом деле всё просто. Бинарные файлы тоже можно сравнивать. Достаточно
    $ git config diff.word.textconv docx2txt
    $ echo '*.docx diff=word' > .gitattributes
    Если документы хранятся в репозитории, то можно легко их сравнить. Конечно форматирование теряется, но программистам и не нужно форматирование. А бухгалтеры всё равно не смогут использовать даже GUI git, чтобы делать это. Если только обёртку для этого написать, но мёржить всё равно не получится, проще их на markdown пересадить.
     
  • 3.65, Аноним (62), 00:00, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Уже давно не бинарные
     
  • 3.66, Аноним (132), 00:03, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий - текстовые. То есть подходят только для исходников и плейн текста, и то очень плохо. А нужна система для DAGов, а не последовательностей строк.
     
     
  • 4.120, пох. (?), 18:46, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий -
    > текстовые.

    хуже - они линейно-ориентированные. html - это в общем текстовый файл. Только от добавления лишнего пробела или переноса строки, ВНЕЗАПНО, не только не портится, как модные-современные форматы, а хуже того - в результирующем его отображении не меняется НИЧЕГО.

    > То есть подходят только для исходников и плейн текста

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

    Но с вордом (и экселом) прикол в том, что они ТОЖЕ линейно-ориентированные, хотя и не плейнтекст. И показать что вот в этой строке поменяли а на б а вон та просто сдвинута ниже - вполне можно. Просто не ждите от шва6одкоистерическ подобного инструмента. Включая для шва6одкиных форматов шва6одкоофиса, не на тех напали.

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

     
  • 3.95, пох. (?), 11:40, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы

    средства для трекинга изменений в которых (пусть бинарные и проприетарные) существуют уже лет двадцать.

    > но я присоединяюсь к вашему недоумению

    спи спокойно, твоей шва6одке они не угрожают
    Сравнить два .odt ты сможешь примерно никогда.

     
  • 3.118, Аноним (8), 18:28, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А какая разница? diff это капля в море возможностей vcs. Посмотреть "как было" и "как стало" можно с абсолютно любым форматом, плюс кто и когда что-то менял. А если постараться, можно и diff сделать. Например, github замечательно умеет diff картинок.
     
  • 2.51, Michael Shigorin (ok), 19:48, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересно почему СКВ популярно только у программистов?

    Ну почему, в девяностые вроде как и у бухгалтеров с дизайнерами СКВ бывали популярны...

     
  • 2.52, Аноним (3), 20:06, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лично я загнал себя в задницу тысячами и тысячами файлов разных версий на диске ... большой текст свёрнут, показать
     
     
  • 3.56, Аноним (3), 20:43, 20/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Главная боль в том, что данные рандомно обновляются. И мне что-то не хватает кнопки СРАВНИТЬ ФАЙЛЫ ПРОХЕШИРОВАВ ОБА в кде, когда предлагает заменить файл с одинаковым именем. Там может несколько байт поменялось, НО ОНИ ВАЖНЫЕ. Как люди вообще с файлами работают? Что-либо найти вообще тяжело, файлы называют чёрте как. Но реально, принудительное тагирование нормальными данными наверное бы помогло.  Все эти файлы замечательно копятся и потом не ясно куда делись десятки терабайт, а тебе срочно нужны терабайты под какие-то данные, а всё забито мусором и частичными дубликатами.
     
     
  • 4.99, Ordu (ok), 13:45, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Как люди вообще с файлами работают?

    Твой case описан крайне мутно, сложно дать конкретный совет. Я упорядочиваю ебуки в чём-то типа wiki построенной на org-mode файликах. Мне плюс-минус пофигу как там называются файлы, потому как если мне что-то надо, я ищу это в org-mode по тегам или ключевым словам, и там есть ссылки на файлы.

    edit: есть универсальный совет под такие проблемы: lisp. lisp позволяет смешивать описание данных и код. То есть ты начинаешь описывать данные в виде s-expressions, а потом добавляешь обвязку, которая автоматизирует самые болезненные действия. Тут я могу порекомендовать [1], в качестве введения в тему. Это правда common lisp, а не что-нибудь хипстерское типа scheme или racket. Но переключиться с CL на scheme/racket не так уж и сложно.

    [1] http://www.gigamonkeys.com/book/

     
     
  • 5.109, Аноним (3), 16:43, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мне нужно управление файлами, полученными из интернета. Допустим, я знаю, что ищу, но найти это, не проследовав на источник в интернете и не получив из него имя искомого файла и дату последнего изменения (а в самом лучшем случае и хэш), не представляется возможным: если я открываю архив. я вижу в нём какие-то бинарные файлы, и что дальше? По соседству может лежать точно такой же файл, более старый по времени изменения и имеющий тот же самый размер, но по факту это более новый файл с кучей изменений. Всё-таки, юзабилити нынешних файловых менеджеров не очень высокое. Было бы неплохо интегрировать систему файл менеджмента (я пока только реализовал подгрузку сведений из интернета, но где-то придётся запускать браузер из-за скриптов и это уже не удобно).
     
     
  • 6.110, Аноним (3), 16:47, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется, в случае с архивами, можно просканировать файл на предмет самого последнего изменения для всех файлов в архиве. Не поможет для изврата, где время изменения подделали, но в целом должно быть нормально. Но это работает только с архивами, с бинарями не получится и тут только считать хэш -- это единственная доступная инфа. Если бы существовал реестр загрузок, хэши для всех файлов в него вполне можно было бы и сохранять. Но они долго считаются. Т_Т
     
     
  • 7.111, Аноним (3), 16:51, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В идеале было бы в процессе загрузки хэши считать. Ну т.е. если скачивать будет скрипт вместо браузера, он может и добавлять всё куда нужно. Однако это мнее удобно, наверное. И опять же проблема: страницы генерируются скриптами, нужно решать капчи, и прочее такое. Почему никто не напишет такое ПО?
     
  • 7.113, Аноним (3), 17:02, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А вот тут что-то можно сделать. Время изменения для локального файла выставлять по последнему обновлённому файлу в архиве. У локального файла архива всё ещё остаётся время создания (даже два, но с ними всегда путаница и второе в glibc только недавно добавили).
     
     
  • 8.126, Аноним (3), 21:46, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я имею в виду, я это сделал шелл, правда , но это не информация об удалённом фа... текст свёрнут, показать
     
  • 2.117, Аноним (8), 18:25, 21/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто мера уровня специалиста. Всё что может периодически изменяться руками нет смысла не хранить в vcs. Да, не для всего можно сделать diff, но diff это только один малюсенький аспект работы с VCS. Посмотреть как было, как стало, кто и когда изменил можно абсолютно всегда. И очень часто нужно.
     

  • 1.85, Аноним (132), 09:23, 21/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256.

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

     
     
  • 2.148, Javaist (?), 18:16, 24/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У них даже локально не все работает, например gitk.
     

  • 1.144, Javaist (?), 21:44, 23/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Уже 2.29.1 вышел
    https://github.com/git/git/commit/b927c80531cca9b9107754186532e8cb00884008
     
     
  • 2.146, Козлетто (?), 09:22, 24/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Уже 2.29.1 вышел
    > https://github.com/git/git/commit/b927c80531cca9b9107754186532e8cb00884008

    GVF=GIT-VERSION-FILE
    - DEF_VER=v2.29.0
    + DEF_VER=v2.29.1
    и весь релиз


     
     
  • 3.147, Javaist (?), 18:15, 24/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это лишь один комминт, там ещё есть. В описании ведь написано что изменилось или ты не читал?
     

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



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

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