Доступен выпуск распределенной системы управления исходными текстами Git 2.26.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52594
SHA-2 разработан АНБ, так что веры к нему нет, но для GIT подойдёт
А какой криптографии есть вера? Вся криптография - это игра в "не успели найти дыру = в домике". Доказательств безопасности считай что нет. "Легко" лишь доказать небезопасность
При чем тут вера ?Сделай шифровку с неограниченным ключом (кому сколько нужно столько и ставит) и юзай делов то.
Так нет же запрещено, у кого то мощностей не хватит это быстро раскрыть.
Шифр вернама же!
Да, шифр Вернама - это действительно решение. Но трудности с передачей ключа и использованием делают его применимым только по особым случаям
в современном мире обменятся огромным набором ключей, как и хранить их не составляет большого труда.
> в современном мире обменятся огромным набором ключей, как и хранить их не
> составляет большого труда.Ага. Руками заливаешь на оптический дису без рв и доставляешь через океан...и так каждому адресату.
Проблема в том, что ключами надо обмениваться по надежному каналу. А шифровать для передачи корреспонденту ключ шифра Вернама другим шифром = сводить безопасность до уровня этого другого шифра
Квантовая крипта это решит - там сообщение разрушается при прочтении. Так старый добрый Вернам еще вернется когда-нибудь.
О квантовой знаю мало, но слышал, что она подает надежды. Правда я боюсь, что она требует дорогостоящих устройств. Да плюс ещё квантовые помпы грозят угробить старый добрый RSA и связанное (хотя новые методы исследуются)
Можно подумать, что у анона есть проблемы с получением налички в кассе лично в день зарплаты))
Как приспичит -- анон ногами в соседний колхоз за 12 км побежит.
к той стойкость которой строго доказана математически, такая криптография есть, учи матчасть.И вообще, главная проблема криптографии в получении достаточно длинной случайной последовательности чисел, в рандоме!!!
Я матчасть знаю и весьма неплохо. Проблема криптографии действительно и в длинным рандомных последовательностях, но ещё большая проблема - обмен ключами. Это одна из самых проблемных областей (до открытия асимметричного шифрования)
> Вся криптография - это игра в "не успели найти дыру = в домике".Не совсем. Криптография бывает хуже.
https://www.washingtonpost.com/graphics/2020/world/national-.../
> SHA-2 разработан АНБА SHA-3?
Всё, что не относится к классу шифров Вернама -- гуано. Пока не _доказано_, что не гуано -- априори гуано.
Blake3 не осилили, остались на анбшном.
То есть вы считаете, что АНБ настолько есть дело до вас, что они, используя сверхсекретную дыру в sha-2, сгенерируют файлик специально чтобы подменить что-то в вашем репозитории?
Это будет логичным финалом.
бгг, причем файлик не просто должен быть с таким же хешем, а еще и иметь осмысленное содержание чтобы ваша репка прошла все линтеры и потом не завалилась при сборке, об этом моменте почему-то всегда забывают когда начинають гнать чушь про поиск коллизий в хешах))
>Продолжено расширение экспериментальной поддержки частичного клонирования (partial clones), позволяющей переносить лишь часть данных и работать с неполной копией репозитория.Почему нельзя тупо сделать как в каком-нибудь svn'е. С сервера вытягивать нужные версии конкретных файлов, клиент получает эти файлы, изменяет, потом обратно загружает их на сервер и сервер у себя делает коммит от имени нужного пользователя. Без загрузки клиенту самих git-объектов.
Сначала нужно решить элементарную проблему и объяснить git, что такое "файл", потому что он ими не оперирует. К сожалению.
Он же их извлекает из своего .git репы,значит может сделать тоже самое + отправить их клиенту.
Гит не работает с файлами. Типовая проверка на собеседовании.Умеет связывать инфу на "файлы", но работает не с файлами, а с изменениями.
Гит хранит blob, tree и commit. Первый - это файл, второе - папка. И все это добро лежит в .git/objects
Ну и мс сделали свой gvfs, значит таки можно.
Почему "к сожалению"? Он оперирует ровно тем, с чем и работает - изменениями
Что значит "он [git] ими [файлами] не оперирует"?Чем же оперируют следующие команды?
git help --all | grep -F file
add Add file contents to the index
archive Create an archive of files from a named tree
checkout Switch branches or restore working tree files
clean Remove untracked files from the working tree
gc Cleanup unnecessary files and optimize the local repository
mv Move or rename a file, a directory, or a symlink
restore Restore working tree files
rm Remove files from the working tree and from the index
...
> Почему нельзя тупо сделать как в каком-нибудь svn'е.патамушта Линус ниасилил svn.
git автоматизирует совершенно бредовый и никому кроме него ненужный workflow вида "пришлите патчи в рассылку, порезав поменьше, у меня экран маленький, нивлизает". Остальное - стройные наборы костылей и подпорок, чтобы эту поделку хоть как-то можно было применить и нормальным разработчикам.
Отсюда все беды - и неумение работать с файлами в том числе.
> совершенно бредовый и никому кроме него ненужныйА, так вот почему он разлетелся по как минимум пяти континентам настолько оперативно и плотно...
как кроновирус
коронавирус
разлетелся он не потому что идеальный, а потому что единственное адекватное решение на тот момент1) для ядра понадобился новая VCS
2) появился гитхаб который сделал гит удобным
3) тулза кросс платформенная
4) лучше всех альтернатив существовавших на тот момент
и много всего другого.. по совокупности качеств он и стал №1
но его есть за что "не любить"...
если бы какой-нибудь GitLab стал бы к примеру WowLab и этот wow был бы лучше проще и прозрачнее гита, то я бы перешел не задумываясь, и мне было бы пох что юзают разработчики ядра к примеру
Тем самым стройная система подпорок и костылей миром признана лучшей. ))))Эта штука не работает с файлом. Нужно прочесть что есть коммит и что есть ветка в гите. Станет прозрачнее. Гит прост невероятно. И прозрачен.
> Тем самым стройная система подпорок и костылей миром признана лучшей. ))))
> Эта штука не работает с файлом. Нужно прочесть что есть коммит и
> что есть ветка в гите. Станет прозрачнее. Гит прост невероятно. И
> прозрачен.это и так понятно, но от этого гит не становится простым или удобным
> патамушта Линус ниасилил svn.Скройся уже, весь опеннет своими экспертными мнениями загадил.
маленький у него, панимаешь.
Твои беды в том, что ты плохо знаешь git, а мнение имеешь.
> Почему нельзя тупо сделать как в каком-нибудь svn'е.Зачем себя истязать гитом если нужно как в svn?
Используй svn и забудь о муках.
я вот ему что попало-то поиспользую! Есть корпоративные стандарты, изволь соблюдать!Только ключи переложи из корня в .verysecuredir/ - там их точно никто не найдет.
Да вроде и проблемы особой нет
Потому что смысл гита был как раз в том, чтобы сделать не как в svn. Svn - это централизованная система, репу хранит сервер, а юзер только рабочим копии на период работы, все свои правки он отгружает на сервер как можно скорее (и следовательно должен иметь к нему доступ).Гит же децентрализован, здесь, рассуждая в терминах svn, каждый "сам себе сервер" и "сам себе рабочая копия". Юзер редачит и коммит у себя, а потом периодически синхронизируется с тем, с кем он хочет
> Гит же децентрализован, здесь, рассуждая в терминах svn, каждый "сам себе сервер" и "сам себе рабочая копия". Юзер редачит и коммит у себя, а потом периодически синхронизируется с тем, с кем он хочетПока не прикрутят туда p2p вся его децентрализация просто миф. Толку что куча народу имеет полный реп у себя, все равно вся синхронизация идет через один (к примеру) github.
Можно малой группой пилить свою фичу в своих репо со своими и иногда доливать в центральный.Если фича оч. большая, то это может быть вариантом.
Какой еще, блин, p2p?Когда-нибудь задавался вопросом, зачем в гитовых командах писать слово origin? Так вот, потому что remote-ов может быть сколько угодно, с разными именами. И это абсолютно нормальный workflow - делать pull-ы друг у друга напрямую.
А уж проблема nat-ов точно не относится к git, прокинуть ssh туннель можно всегда.
> Когда-нибудь задавался вопросом, зачем в гитовых командах писать слово origin?Вот пока есть origin ни про какую децентрализацию можно и не писать.
У вас может быть несколько ремоутов, и они могут указывать на любой репозиторий, включая локальный, размещенный на файловой системе. То есть, я могу к своему проекту мобильного приложения добавить ремоут на ядро линукса. И всё будет работать.В этом и есть децентрализация.
децентрализация это когда полный реп у всех и если кто-то пропадет (станет недоступен)
то все остальные даже не заметят, а как тот пропавший появится то он синхронизируется до остальных.А то что ВЫ называете децентрализацией просто части репа в разных местах.
Про торренты слышали ?
> децентрализация это когда полный реп у всех и если кто-то пропадет ..Так и есть, у всех разработчиков своя версия репозитория. Хочешь, с репозитория васяна делай пулл, хочешь, пушь в его репозиторий. Протокол весьма низкоуровневый и любую децентрализованную обвязку можно написать поверх гита, не изменяя структуры самого гита.
> Про торренты слышали ?
Которые централизованно лежат на рутрекере. "Раздача обновилась просьба скачать торрент файл заново"
> Которые централизованно лежат на рутрекере.Там просто реализация такая, скачал и отвалил. Вот с github тоже что то подобное сделали, по сути централизованное хранилище, а это не правильно.
Правильно... Не правильно... Это удобно, потому как много репов в одном месте, потому как интерфейс для пуллреквестов, ишьюз, красивые графы, и всё что угодно. Такое можно было бы запилить децентрализованно, чтобы каждый форкнувший своими силами хостил бы свой форк, но... эмм... это может и правильнее идеологически, но тем, кто пишет код, не нужно. Ну, реально, ковырялся я в чьём-то коде, нашёл косяк, форкнул, исправил, отправил пулл-реквест, забыл про этот форк и про пуллреквест тоже. Мне не надо неделями хостить этот форк, дожидаясь когда мой пуллреквест будет изучен принимающей стороной, когда они всё обсудят и сделают git pull. Хостить форки -- это головная боль github'а, а не моя.
А оно именно как торренты и работает. Ты добавил ремот с каким-то фильтром - считай, что в клиент сунул торрент-файл. Если на ремоте чт-то изменилось - как и в торренте если торрент-файл на трекере изменился - автоматом тебе ничего не затащит и твоё текущее состояние не попортит. Надо тебе - проапдейтился.
Ты же знаешь, что можно не качать весь торрент, а только то что нужно?Почитай про git, и про торренты заодно.
> Толку что куча народу имеет полный реп у себя, все равно вся синхронизация идет через один (к примеру) github.man git-remote
Ты можешь синхронизироваться с кем угодно. Но скорее всего, ты не хочешь синхронизироваться с кем угодно, скорее всего тебе хочется синхронизироваться с ремотом, которому ты худо-бедно доверяешь.
Пацаны, докачку в git уже сделали? (я не следил)
git fetch && git pull
> git fetch && git pullgit pull == git fetch BRANCH + git merge BRANCH. Не понял вас
(не) очень жаль.
> (не) очень жаль.Будьте добры, потрудитесь объяснить, что вы имели в виду? Я на самом деле не понял. Зачем дважды репу фетчить?
Да все ты понял.
И понятно, что хочешь так намекнуть, что ты то _знаешь_ git. Не то что другие.
Хорошистом в школе был?P.S. Кстати у тебя ошибка - не "git merge BRANCH" а "git merge FETCH_HEAD"
Вот из git help pull:
"git pull is shorthand for git fetch followed by git merge FETCH_HEAD"
> Да все ты понял.Вы говорите загадками. Зачем вы говорите загадками, не делайте так
Вообще то пора уже давно сделать git децентрализованным.
ты с svn богомерзким случайно не перепутал? ))