The OpenNET Project / Index page

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

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

23.03.2020 12:39

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

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

  • Осуществлён переход по умолчанию на вторую версию коммуникационного протокола Git, который используется при удалённом подключении клиента к Git-серверу. Вторая версия протокола примечательна предоставлением возможности фильтрации веток и тегов на стороне сервера с отдачей клиенту сокращённого списка ссылок. Ранее при выполнении любой команды извлечения клиенту всегда отправлялся полный список ссылок во всём репозитории, даже когда клиент обновлял только одну ветку или проверял актуальность своей копии репозитория. Другим заметным новшеством является возможность добавления в протокол новых возможностей по мере появления в инструментарии новой функциональности. Код клиента остаётся совместимым со старым протоколом и может продолжать работать как с новыми, так и со старыми серверами, автоматически откатываясь на первую версию, если сервер не поддерживает вторую.
  • В команду "git config" добавлена опция "--show-scope" упрощающая выявление места, в котором определены те или иные настройки. Git позволяет определять настройки в разных местах: в репозитории (.git/info/config), в каталоге пользователя (~/.gitconfig), в общесистемном файле конфигурации (/etc/gitconfig), а также через опции командной строки и переменные окружения. При выполнении "git config" достаточно трудно понять, где именно определена искомая настройка. Для решения данной задачи была доступна опция "--show-origin", но она лишь показывает путь к файлу, в котором определена настройка, что полезно при намерении отредактировать файл, но не помогает, если требуется изменить значение через "git config" при помощи опций "--system", "--global" или "--local". Новая опция "--show-scope" отображает контекст определения переменных и может применяться совместно с --show-origin":
    
       $ git --list --show-scope --show-origin
       global  file:/home/user/.gitconfig      diff.interhunkcontext=1
       global  file:/home/user/.gitconfig      push.default=current
       [...]
       local   file:.git/config      branch.master.remote=origin
       local   file:.git/config      branch.master.merge=refs/heads/master
    
       $ git config --show-scope --get-regexp 'diff.*'
       global  diff.statgraphwidth 35
       local   diff.colormoved plain
    
       $ git config --global --unset diff.statgraphwidth
    
  • В настройках привязки учётных данных разрешено использование масок в URL. Любые настройки HTTP и учётные данные в Git могут быть установлены как для всех соединений (http.extraHeader, credential.helper), так и для соединений в привязке к URL (credential.https://example.com.helper, credential.https://example.com.helper). До сих пор использование масок, таких как *.example.com, допускалось только для настроек HTTP, но не поддерживалось для привязки учётных данных. В Git 2.26 данные различия устранены и, например, для привязки имени пользователя ко всем поддоменам теперь можно указать:
    
       [credential "https://*.example.com"]
    
       username = ttaylorr
    
  • Продолжено расширение экспериментальной поддержки частичного клонирования (partial clones), позволяющей переносить лишь часть данных и работать с неполной копией репозитория. В новом выпуске добавлена новая команда "git sparse-checkout add", которая позволяет добавлять отдельные директории для применения операции "checkout" лишь к части рабочего дерева, вместо перечисления всех подобных директорий разом через команду "git sparse-checkout set" (можно добавлять по одной директории, без повторного задания всего списка каждый раз). Например, для клонирования репозитория git/git без передачи блобов, ограничения проверки только корневым каталогом рабочей копии и раздельной пометкой для извлечения каталогов "t" и "Documentation", можно указать:
    
       $ git clone --filter=blob:none --sparse git@github.com:git/git.git
    
       $ cd git
       $ git sparse-checkout init --cone
    
       $ git sparse-checkout add t
       ....
       $ git sparse-checkout add Documentation
       ....
       $ git sparse-checkout list
       Documentation
       t
    
  • Заметно увеличена производительность команды "git grep", применяемой для поиска как в актуальном содержимом репозитория, так и в исторических ревизиях. Для ускорения поиска допускалось сканирование содержимого рабочего дерева с использованием нескольких потоков ("git grep --threads"), но поиск в исторических ревизиях был однопоточным. Теперь это ограничение снято за счёт реализации возможности распараллеливания операций чтения из хранилища объектов. По умолчанию число потоков устанавливается равным числу ядер CPU, что в большинстве случаев теперь не требует явного выставления опции "--threads".
  • Добавлена поддержка автодополнения ввода подкоманд, путей, ссылок и прочих аргументов команды "git worktree", позволяющей работать с несколькими рабочими копиями репозитория.
  • Добавлена поддержка ярких цветов, для которых имеются ANSI escape-последовательности. Например, в настройках цветов подсветки "git config --color" или "git diff --color-moved" через опцию "--format" для ярко-голубого можно указывать "%C(brightblue)".
  • Добавлена новая версия скрипта fsmonitor-watchman, обеспечивающего интеграцию с механизмом Facebook Watchman для ускорения отслеживания изменения файлов и появления новых файлов. После обновления git требуется заменить hook в репозитории.
  • Добавлены оптимизации для ускорения операций частичного клонирования (partial clones), связанные с применением битовых карт (bitmap machinery) во избежание полного перебора всех объектов во время фильтрации отдачи. Проверка на BLOB-ы (--filter=blob:none и --filter=blob:limit=n) при частичном клонировании теперь производится существенно быстрее. GitHub объявил о применении патчей с данными оптимизациями и экспериментальной поддержке частичного клонирования.
  • Команда "git rebase" переведена на другой бэкенд, использующий по умолчанию механизм 'merge' (раньше использовался для "rebase -i") вместо 'patch+apply'. В некоторых мелочах бэкенды отличаются, например, после продолжения операции после устранения конфликта (git rebase --continue) новый бэкенд предлагает отредактировать сообщение коммита, а старый просто использовал старое сообщение. Для возвращения старого поведения можно использовать опцию "--apply" или установить переменную конфигурации 'rebase.backend' в значение 'apply'.
  • Пример обработчика параметров аутентификации, заданных через .netrc, приведён к виду, пригодному для использования из коробки.
  • Добавлена настройка gpg.minTrustLevel для задания минимального уровня доверия для различных элементов, выполняющих проверку цифровой подписи.
  • В "git rm" и "git stash" добавлена опция "--pathspec-from-file".
  • Продолжено усовершенствование тестовых наборов в рамках подготовки к переходу на алгоритм хеширования SHA-2 вместо SHA-1.


  1. Главная ссылка к новости (https://lkml.org/lkml/2020/3/2...)
  2. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.25
  3. OpenNews: Подготовлена реализация Git на Shell
  4. OpenNews: Обновление Git с устранением 8 уязвимостей
  5. OpenNews: Представлена вторая версия протокола Git
  6. OpenNews: Для OpenBSD развивается новая git-совместимая система контроля версий Got
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/52594-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (56) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Z (??), 19:00, 23/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    SHA-2 разработан АНБ, так что веры к нему нет, но для GIT подойдёт
     
     
  • 2.17, Аноним (17), 06:17, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А какой криптографии есть вера? Вся криптография - это игра в "не успели найти дыру = в домике". Доказательств безопасности считай что нет. "Легко" лишь доказать небезопасность
     
     
  • 3.20, Аноним (20), 08:42, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    При чем тут вера ?

    Сделай шифровку с неограниченным ключом (кому сколько нужно столько и ставит) и юзай делов то.
    Так нет же запрещено, у кого то мощностей не хватит это быстро раскрыть.

     
  • 3.30, псевдонимус (?), 11:05, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Шифр вернама же!
     
     
  • 4.38, Аноним (17), 15:00, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, шифр Вернама - это действительно решение. Но трудности с передачей ключа и использованием делают его применимым только по особым случаям
     
     
  • 5.39, анон (?), 16:53, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    в современном мире обменятся огромным набором ключей, как и хранить их не составляет большого труда.
     
     
  • 6.43, псевдонимус (?), 20:08, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > в современном мире обменятся огромным набором ключей, как и хранить их не
    > составляет большого труда.

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


     
  • 6.54, Аноним (54), 16:11, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проблема в том, что ключами надо обмениваться по надежному каналу. А шифровать для передачи корреспонденту ключ шифра Вернама другим шифром = сводить безопасность до уровня этого другого шифра

     
     
  • 7.55, Аноним (55), 21:31, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Квантовая крипта это решит - там сообщение разрушается при прочтении. Так старый добрый Вернам еще вернется когда-нибудь.
     
     
  • 8.56, Аноним (17), 21:45, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    О квантовой знаю мало, но слышал, что она подает надежды Правда я боюсь, что он... текст свёрнут, показать
     
  • 5.50, Брат Анон (?), 08:35, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать, что у анона есть проблемы с получением налички в кассе лично в день зарплаты))
    Как приспичит -- анон ногами в соседний колхоз за 12 км побежит.
     
  • 3.40, анон (?), 16:58, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    к той стойкость которой строго доказана математически, такая криптография есть, учи матчасть.

    И вообще, главная проблема криптографии в получении достаточно длинной случайной последовательности чисел, в рандоме!!!

     
     
  • 4.53, Аноним (54), 16:09, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я матчасть знаю и весьма неплохо. Проблема криптографии действительно и в длинным рандомных последовательностях, но ещё большая проблема - обмен ключами. Это одна из самых проблемных областей (до открытия асимметричного шифрования)
     
  • 3.52, Ordu (ok), 09:13, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вся криптография - это игра в "не успели найти дыру = в домике".

    Не совсем. Криптография бывает хуже.

    https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypt

     
  • 2.23, Ilya Indigo (ok), 09:07, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > SHA-2 разработан АНБ

    А SHA-3?

     
     
  • 3.51, Брат Анон (?), 08:36, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё, что не относится к классу шифров Вернама -- гуано. Пока не _доказано_, что не гуано -- априори гуано.
     

  • 1.2, Аноним (2), 20:04, 23/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Blake3 не осилили, остались на анбшном.
     
     
  • 2.18, Аноним (17), 06:18, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То есть вы считаете, что АНБ настолько есть дело до вас, что они, используя сверхсекретную дыру в sha-2, сгенерируют файлик специально чтобы подменить что-то в вашем репозитории?
     
     
  • 3.28, Аноним (2), 10:21, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это будет логичным финалом.
     
  • 3.41, анон (?), 17:01, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    бгг, причем файлик не просто должен быть с таким же хешем, а еще и иметь осмысленное содержание чтобы ваша репка прошла все линтеры и потом не завалилась при сборке, об этом моменте почему-то всегда забывают когда начинають гнать чушь про поиск коллизий в хешах))
     

  • 1.3, Аноним (3), 20:10, 23/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Продолжено расширение экспериментальной поддержки частичного клонирования (partial clones), позволяющей переносить лишь часть данных и работать с неполной копией репозитория.

    Почему нельзя тупо сделать как в каком-нибудь svn'е. С сервера вытягивать нужные версии конкретных файлов, клиент получает эти файлы, изменяет, потом обратно загружает их на сервер и сервер у себя делает коммит от имени нужного пользователя. Без загрузки клиенту самих git-объектов.

     
     
  • 2.4, Андрей (??), 20:20, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сначала нужно решить элементарную проблему и объяснить git, что такое "файл", потому что он ими не оперирует. К сожалению.
     
     
  • 3.5, Аноним (3), 20:27, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он же их извлекает из своего .git репы,значит может сделать тоже самое + отправить их клиенту.
     
     
  • 4.24, А (??), 09:42, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гит не работает с файлами. Типовая проверка на собеседовании.

    Умеет связывать инфу на "файлы", но работает не с файлами, а с изменениями.

     
     
  • 5.49, Аноним (49), 05:21, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Гит хранит blob, tree и commit. Первый - это файл, второе - папка. И все это добро лежит в .git/objects
    Ну и мс сделали свой gvfs, значит таки можно.
     
  • 3.36, Crazy Alex (ok), 13:37, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почему "к сожалению"? Он оперирует ровно тем, с чем и работает - изменениями
     
  • 2.6, нах. (?), 21:26, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • –15 +/
    > Почему нельзя тупо сделать как в каком-нибудь svn'е.

    патамушта Линус ниасилил svn.

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

    Отсюда все беды - и неумение работать с файлами в том числе.

     
     
  • 3.10, Michael Shigorin (ok), 00:08, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > совершенно бредовый и никому кроме него ненужный

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

     
     
  • 4.11, ё (?), 00:57, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    как кроновирус
     
  • 4.12, ё (?), 00:58, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    коронавирус
     
  • 4.13, хотел спросить (?), 02:35, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    разлетелся он не потому что идеальный, а потому что единственное адекватное решение на тот момент

    1) для ядра понадобился новая VCS

    2) появился гитхаб который сделал гит удобным

    3) тулза кросс платформенная

    4) лучше всех альтернатив существовавших на тот момент

    и много всего другого.. по совокупности качеств он и стал №1

    но его есть за что "не любить"...

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

     
     
  • 5.25, А (??), 09:46, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тем самым стройная система подпорок и костылей миром признана лучшей. ))))

    Эта штука не работает с файлом. Нужно прочесть что есть коммит и что есть ветка в гите. Станет прозрачнее. Гит прост невероятно. И прозрачен.

     
     
  • 6.44, хотел спросить (?), 20:15, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Тем самым стройная система подпорок и костылей миром признана лучшей. ))))
    > Эта штука не работает с файлом. Нужно прочесть что есть коммит и
    > что есть ветка в гите. Станет прозрачнее. Гит прост невероятно. И
    > прозрачен.

    это и так понятно, но от этого гит не становится простым или удобным

     
  • 3.15, Аноним (15), 05:18, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > патамушта Линус ниасилил svn.

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

     
  • 2.7, Аноним (7), 22:15, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    > Почему нельзя тупо сделать как в каком-нибудь svn'е.

    Зачем себя истязать гитом если нужно как в svn?
    Используй svn и забудь о муках.

     
     
  • 3.9, менеджер (?), 23:03, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я вот ему что попало-то поиспользую! Есть корпоративные стандарты, изволь соблюдать!

    Только ключи переложи из корня в .verysecuredir/ - там их точно никто не найдет.

     
  • 2.8, коржик (?), 22:22, 23/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да вроде и проблемы особой нет
     
  • 2.19, Аноним (17), 06:20, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что смысл гита был как раз в том, чтобы сделать не как в svn. Svn - это централизованная система, репу хранит сервер, а юзер только рабочим копии на период работы, все свои правки он отгружает на сервер как можно скорее (и следовательно должен иметь к нему доступ).

    Гит же децентрализован, здесь, рассуждая в терминах svn, каждый "сам себе сервер" и "сам себе рабочая копия". Юзер редачит и коммит у себя, а потом периодически синхронизируется с тем, с кем он хочет

     
     
  • 3.22, Аноним (20), 08:52, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Гит же децентрализован, здесь, рассуждая в терминах svn, каждый "сам себе сервер" и "сам себе рабочая копия". Юзер редачит и коммит у себя, а потом периодически синхронизируется с тем, с кем он хочет

    Пока не прикрутят туда p2p вся его децентрализация просто миф. Толку что куча народу имеет полный реп у себя, все равно вся синхронизация идет через один (к примеру) github.

     
     
  • 4.26, А (??), 09:51, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно малой группой пилить свою фичу в своих репо со своими и иногда доливать в центральный.

    Если фича оч. большая, то это может быть вариантом.

     
  • 4.27, Аноним (27), 10:00, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Какой еще, блин, p2p?

    Когда-нибудь задавался вопросом, зачем в гитовых командах писать слово origin? Так вот, потому что remote-ов может быть сколько угодно, с разными именами. И это абсолютно нормальный workflow - делать pull-ы друг у друга напрямую.

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

     
     
  • 5.29, Аноним (20), 10:24, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Когда-нибудь задавался вопросом, зачем в гитовых командах писать слово origin?

    Вот пока есть origin ни про какую децентрализацию можно и не писать.

     
     
  • 6.31, коржик (?), 11:53, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У вас может быть несколько ремоутов, и они могут указывать на любой репозиторий, включая локальный, размещенный на файловой системе. То есть, я могу к своему проекту мобильного приложения добавить ремоут на ядро линукса. И всё будет работать.

    В этом и есть децентрализация.

     
     
  • 7.32, Аноним (20), 12:00, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    децентрализация это когда полный реп у всех и если кто-то пропадет (станет недоступен)
    то все остальные даже не заметят, а как тот пропавший появится то он синхронизируется до остальных.

    А то что ВЫ называете децентрализацией просто части репа в разных местах.

    Про торренты слышали ?

     
     
  • 8.33, коржик (?), 12:40, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так и есть, у всех разработчиков своя версия репозитория Хочешь, с репозитория ... текст свёрнут, показать
     
     
  • 9.35, Аноним (20), 12:59, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там просто реализация такая, скачал и отвалил Вот с github тоже что то подобное... текст свёрнут, показать
     
     
  • 10.58, Ordu (ok), 17:02, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно Не правильно Это удобно, потому как много репов в одном месте, п... текст свёрнут, показать
     
  • 8.37, Crazy Alex (ok), 14:01, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А оно именно как торренты и работает Ты добавил ремот с каким-то фильтром - счи... текст свёрнут, показать
     
  • 8.48, Аноним (15), 01:30, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты же знаешь, что можно не качать весь торрент, а только то что нужно Почитай п... текст свёрнут, показать
     
  • 4.57, Ordu (ok), 16:57, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Толку что куча народу имеет полный реп у себя, все равно вся синхронизация идет через один (к примеру) github.

    man git-remote

    Ты можешь синхронизироваться с кем угодно. Но скорее всего, ты не хочешь синхронизироваться с кем угодно, скорее всего тебе хочется синхронизироваться с ремотом, которому ты худо-бедно доверяешь.

     

  • 1.14, Аноним (14), 04:34, 24/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пацаны, докачку в git уже сделали? (я не следил)
     
     
  • 2.16, Аноним (15), 05:20, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    git fetch && git pull
     
     
  • 3.34, коржик (?), 12:41, 24/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > git fetch && git pull

    git pull == git fetch BRANCH + git merge BRANCH. Не понял вас

     
     
  • 4.47, Аноним (15), 01:28, 25/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    (не) очень жаль.
     
     
  • 5.59, коржик (?), 22:16, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > (не) очень жаль.

    Будьте добры, потрудитесь объяснить, что вы имели в виду? Я на самом деле не понял. Зачем дважды репу фетчить?

     

  • 1.21, Аноним (20), 08:47, 24/03/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –5 +/
     
     
  • 2.42, анон (?), 17:06, 24/03/2020 Скрыто модератором
  • –1 +/
     

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



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

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