The OpenNET Project / Index page

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

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

04.10.2022 10:54

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

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

  • В основной состав включена утилита "scalar", разработанная компанией Microsoft для управления крупными репозиториями. Утилита изначально была написана на языке C#, но в git включён переделанный вариант на языке Си. Новая утилита отличается от команды git включением по умолчанию дополнительных возможностей и настроек, влияющих на производительность при работе с очень крупными репозиториями. Например, при использовании scalar применяется:
    • Частичное клонирование для работы с неполной копией репозитория.
    • Встроенный механизм отслеживания изменений в файловой системе (FSMonitor), позволяющий обойтись без перебора всего рабочего каталога.
    • Индексы, охватывающие объекты в разных pack-файлах (multi-pack).
    • Файлы commit-graph с индексом графа коммитов, применяемым для оптимизации доступа к информации о коммитах.
    • Фоновые периодические работы для поддержания оптимальной структуры репозитория в фоновом режиме, не блокируя интерактивный сеанс (раз в час выполняется работа по упреждающей загрузке свежих объектов из удалённого репозитория и обновлению файла с графом коммитов, а каждую ночь запускается процесс упаковки репозитория).
    • Режим "sparseCheckoutCone", ограничивающий допустимые шаблоны при частичном клонировании.
  • В команду "git rebase" добавлена опция "--update-refs" для обновления зависимых веток, пересекающихся с перемещаемыми ветками, чтобы вручную не выполнять операции checkout к каждой зависимой ветке для переключения на требуемый коммит.
  • Обеспечена совместимость команды "git rm" с частичными индексами.
  • Улучшено поведение команды "git mv A B" при перемещении файла из рабочей области с частичными индексами в режиме "cone" во внешнюю область, для которой данный режим не применяется.
  • Проведена оптимизация формата bitmap-фалов для работы с большими репозиториями - добавлена опциональная индексная таблица со списком выбранных коммитов и их смещений.
  • В команде "git merge-tree" реализован новый режим при котором на основе двух указанных коммитов вычисляется дерево с результатом слияния, так, как если бы истории этих коммитов были объединены.
  • Добавлена настройка "safe.barerepository" для управления возможностью размещения bare-репозиториев (репозитории, не содержащие рабочего дерева) внутри других git-репозиториев. При установке в значение "explicit" будет допускаться работа с bare-репозиториями, размещёнными только в верхнем каталоге. Для возможности размещения bare-репозиториев в подкаталогах следует использовать значение "all".
  • В команду "git grep" добавлена опция "-m" ("--max-count"), аналогичная одноимённой опции в GNU grep и позволяющая ограничить число выводимых совпадений.
  • В команде "ls-files" реализована опция "--format" для настройки выводимых полей (например, можно включить вывод имени объекта, режимов и т.п.).
  • В "git cat-file" при показе содержимого объектов реализована возможность учёта привязок авторов к email, заданных в файле mailmap.


  1. Главная ссылка к новости (https://lore.kernel.org/all/xm...)
  2. OpenNews: Выпуск системы управления исходными текстами Git 2.37
  3. OpenNews: Две уязвимости в Git
  4. OpenNews: Уязвимость в Git, приводящая к утечке учётных данных
  5. OpenNews: Критическая уязвимость в Git LFS, проявляющаяся на платформе Windows
  6. OpenNews: Обновление Git с устранением уязвимости, допускающей удалённое выполнение кода
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/57868-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, васёк (?), 11:47, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    спасибо Линусу за подгон, а то SVC скучная была
     
     
  • 2.2, Аноним (2), 11:53, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Он вроде под впечатлением от перфорса запилил сабж. Не сказал бы, что перфорс -- скучный.
     
     
  • 3.4, Аноним (4), 12:22, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Под впечатлением от кидалова со стороны биткипера. И вообще гит это клон биткипера.
     
     
  • 4.69, myhand (ok), 07:27, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Угу.  А линукс - клон миникс.
     
  • 3.7, Anonymus (?), 13:10, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    inspired by BitKeeper
     
     
  • 4.15, Аноним (15), 15:11, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кстати если бы создатель биткипера тогда не взбрыкнул, наверняка бы уже давно озолотился.
     

  • 1.6, fumanchez (ok), 12:51, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/


    /*
    * Unfortunately, Scalar's Functional Tests demonstrated
    * that the untracked cache feature is unreliable on Windows
    * (which is a bummer because that platform would benefit the
    * most from it). For some reason, freshly created files seem
    * not to update the directory's 'lastModified' time
    * immediately, but the untracked cache would need to rely on
    * that.
    *
    * Therefore, with a sad heart, we disable this very useful
    * feature on Windows.
    */


    Жалко пацанов на Windows

     
     
  • 2.18, Аноним (18), 15:29, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На C# все работало. Переписали на Си всё сломалось.
     
     
  • 3.67, Аноним (67), 03:43, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На C# тоже не работало.
     
  • 2.80, Аристарх (??), 15:04, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне кажется, эти "мастера" чего-то не учли. Не может на "промышленной" ФС быть такая петрушка. Может, они решили поиграть в хакеров и по привычке лезут сразу в сектора? :) NTFS - весьма надёжная штука и сомнительно, что там что-то "не обновляется вовремя" (если не отключено вообще). Просто надо пользоваться документированными фичами.
     
  • 2.91, Аноним (91), 16:59, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пацанов на windows нет. В любом случае, не жалко.
     

  • 1.9, Аноним (9), 14:52, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Как надёжно получить имя родительского бранча от которого стартанула текущая ветка? Без обмазывания awk/sed которые начнут фигню выводить как только что-то будет не в том порядке выдано
     
     
  • 2.10, Аноним (10), 14:54, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никак потому что это не нужно. У тебя проблема в процессах и гит тут не причём.
     
     
  • 3.13, Аноним (9), 14:58, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У меня нет проблемы в процессах. У тебя есть проблема в понимании проблемы. Возьми хоть тот же Git Flow. У тебя от мастера бранчуется Develop, от Develop фичи, ещё иногда у тебя ответвляются хотфиксы, релизы и прочее. И постоянно нужно следить, откуда куда ты делаешь MR. В то же время для gitlab можно цель для мержа из cli передавать. Почему бы этим не пользоваться, чтобы уменьшить головняк?!
     
     
  • 4.14, Аноним (15), 15:10, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что гит флоу это сбоку придуманный велосипед? Если это прям важно единственное верный способ это github flow.
     
  • 2.27, Аноним (27), 17:11, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет такой задачи — получить имя родительской ветки, не рассказывай сказок. Чего именно ты пытаешься достичь? Каковая конечная цель?
     
     
  • 3.34, Аноним (34), 18:07, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Конечная цель - замержить фичу в ту же ветку, откуда фиче-бранч отбранчевался.
     
     
  • 4.43, pashev.ru (?), 20:33, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    branch-foo —> my/branch-foo/feature-xxx
     
     
  • 5.56, Аноним (9), 23:20, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    и что?
     
  • 4.98, Аноним (98), 01:59, 08/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это какой-то изврат.
    Не фича должна искать куда ей пристроиться.
    Это ветка решает какая ей фича нужна и мержит эту фичу.

    И, для общего понимания.
    1. В гите нет иерархии веток. Поэтому нет родительских и дочерних веток. Да и вообще нет сущности "ветка".

    2. Ветка в гите это обычный файл размером 41 байт содержащий хеш коммита.
    Например вот я создал ветку
    $ cat .git/refs/heads/master
    94b961ed56dde33ba2acf4e44db68fd19278d320

    echo "94b961ed56dde33ba2acf4e44db68fd19278d320" > .git/refs/heads/main

    Какая из этих веток "родительская" для
    echo "94b961ed56dde33ba2acf4e44db68fd19278d320" > .git/refs/heads/feature_1

     
  • 2.92, Аноним (91), 17:03, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Как надёжно получить имя родительского бранча от которого стартанула текущая ветка?

    Никак, нет такой сущности.

     

  • 1.12, Аноним (9), 14:55, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как проверить, запушен ли коммит на сервер?
    И если да, в каком локальном хуке можно прописать что ребейс и --amend ему делать нельзя?
     
     
  • 2.24, Аноним (24), 16:34, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    git merge-base <BRANCH> <REMOTE>/<BRANCH>

    вывелеи последний общий коммит

     
     
  • 3.57, Аноним (9), 23:20, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне нравится эта идея, спасибо, поковыряю на досуге
     

  • 1.29, Аноним (29), 17:20, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Git вообще не нужон. Лишнее усложнение процесса.
     
     
  • 2.51, Neon (??), 21:07, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Тоже никогда не понимал прелестей Git'a. Всегда в команде хватало для совместной разработки SVN. Просто и сердито. И никаких извращений от Git'a ни разу не потребовались
     
     
  • 3.61, Аноним (61), 00:45, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > SVN

    Не нужно. Проще и быстрее скопировать в папку и перекинуть её через самбу. А современные редакторы умеют подсвечивать разницу если нужно слить несколько файлов в один.

     
  • 2.63, Аноним (63), 00:49, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Плюсану адеквата. Гит по сложности сам тянет на докторскую диссертацию. Лично я как открыл официальную документацию, сразу понял, что все эти команды в голове удержать нереально, если ими не пользоваться по несколько раз в день. Поэтому если содержать сервер гита, этим должен заниматься отдельный человек на отдельной должности.
     
     
  • 3.70, myhand (ok), 07:30, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если командами гита не пользоваться каждый день - гит не нужен, да.

     
     
  • 4.71, Lex20 (ok), 08:23, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ctrl+shift+j в idea в конце рабочего дня, выбрать разницу и влить в репозитарий. Вот и весь git
     
     
  • 5.73, Аноним (73), 10:16, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ctrl+shift+j в idea это же "Join lines", при чём тут Git?
     
  • 3.72, john_erohin (?), 09:39, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Гит по сложности сам тянет на докторскую диссертацию

    поэтому необходимо упрощать: выделить мнимальное подмножество
    для своих задач и пользоваться только им.

     
  • 3.94, Аноним (91), 17:14, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы наверное разработкой не занимаетесь, так зачем вам гит? Пиццу доставлять или улицы подметать VCS не нужна.

    > все эти команды в голове удержать нереально

    Все команды никому не нужны. Для таких как вы вполне хватит init и commit. Если вас пустят в публичный репозиторий, в чём я сомневаюсь, ещё pull и push.

    > Поэтому если содержать сервер гита

    "Сервера гита" не существует, это просто обычный репозиторий доступный через ssh. Не нужен никакой человек чтобы его поддерживать, ещё и поддерживать-то не нужно.

     
     
  • 4.102, Аноним (102), 04:43, 08/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы наверное разработкой не занимаетесь

    Нет, не занимаюсь. К счастью, работаю в государственной компании и занимаюсь серьезными проектами, а не клепаю формочки на модных фреймворках. И вообще, слово "разработка" ругательно для программиста с профильным техническим образованием.

     
  • 2.78, Аноним (78), 06:51, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Не вижу смысла в системах контроля версий. Можно просто скопировать папку с исходниками или быстро в WinRAR заархивировать
     
     
  • 3.85, Аноним (9), 15:33, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Не вижу смысла в системах контроля версий. Можно просто скопировать папку с
    > исходниками или быстро в WinRAR заархивировать

    О, ещё и за WinRAR надо чайным пакетиком по соплям шлёпать

     
  • 3.88, Аноним (88), 17:03, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пенсионер, ты застрял в нулевых, сейчас есть 7z который в разы лучше
     
  • 2.93, Аноним (91), 17:04, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да, процесса обмена .rar архивами черех яндекс.диск. А то понапридумывают каких-то гитов...
     

  • 1.33, Аноним (33), 17:57, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, используется ли Git во время разработки самого Git?
     
     
  • 2.36, yet another anonymous (?), 18:10, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да.
     
  • 2.38, ТрахерЪ (?), 19:17, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем его разрабатывать
     

  • 1.35, Аноним (35), 18:07, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Знакомая работала в гос. организации и там писала программы для спутников. Программы там писали на си, а вместо git использовали флешки.

    Это доказывает что настоящим программистам git не нужен, достаточно только Си и флешки

     
     
  • 2.39, n00by (ok), 19:29, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Все знают эту знакомую. Только там не флешки были, а ферритовые кольца.
     
     
  • 3.54, Аноним (54), 21:49, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В спутниках были микроконтроллеры МИЛАНДР, сомневаюсь что к ним можно подключить ферритовые кольца.
     
     
  • 4.76, n00by (ok), 15:52, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Знакомая эта, Фантазия, она что угодно куда угодно подключит. И на Си напишет.
     
  • 2.42, Аноним (42), 20:32, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Работал в гос компании. Да всё так. Бекапы рулят.
     
     
  • 3.48, Аноним (9), 20:41, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Лжец, в тру госах нет денег на "эти какие-то там бэкапы погромистов", вот они и носят всё на собственных флешках. Флешки дешёвые, дохнут регулярно
     
     
  • 4.50, n00by (ok), 20:56, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет денег запустить гит на локальной машине?
     
     
  • 5.55, Аноним (9), 23:19, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Посыл был про бекапы. Что касается гита, то в госах обычно у контингента нет понимания что есть какие-то СКВ и их зачем-то нужно делать. И разумеется чем у меньшего числа есть исходники, тем больше шансов ещё денёк посидеть с работой
     
     
  • 6.77, n00by (ok), 15:59, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Посыл был, что тру госы - это в канадьчине?
     
     
  • 7.86, Аноним (9), 15:34, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Везде то вам влияние забугорья мерещится, где у самих помойка
     
     
  • 8.87, n00by (ok), 16:27, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Написано же 171 тру 187 - значит забугорье Здесь ФССП хватило средств на бе... текст свёрнут, показать
     
  • 2.46, Советский инженер и пенсионер (?), 20:39, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    ИДИOT! Помимо "флэшек" есть ещё и сеть c FTP и Samba. Так что валил бы ты отсюда со своим петросянством.
     
     
  • 3.53, Аноним (54), 21:44, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это абсолютно реальная ситуация.
    Какой-то общий сервер там действительно был, но почему-то пользовались флешками.
     
     
  • 4.58, Аноним (58), 23:55, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Полностью подтверждаю.
    Я должен был осуществить приёмку у подрядчика (НИИ) исходных кодов на объекте.

    Так они свалили с обьекта в закат со словами "Исходный код в папке год/месяц/день".

    Это у них такая система контроля версий была.

     
  • 3.79, Аноним (78), 07:09, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот вот, вместо того чтобы свободный gitlab запустить или любую другую систему контроля версий, люди мучают флешки и общий сервер.
     
     
  • 4.89, Аноним (88), 17:05, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > gitlab

    Смузихлёбское поделие. В серьезных компаниях нигде не используют. П.с. Серьезные компании - это не вэб "разработка".

     

  • 1.40, Full Master (?), 19:48, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >В команду "git rebase" добавлена опция "--update-refs" для обновления зависимых веток, пересекающихся с перемещаемыми ветками, чтобы вручную не выполнять операции checkout к каждой зависимой ветке для переключения на требуемый коммит.

    Джва года ждал.

     
     
  • 2.81, Аристарх (??), 15:07, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Откровенно, я даже формулировки этого улучшения не понял. :) Я знаю, что такое ветки, коммиты, мержи, но вот эта белиберда в описании выше моего понимания. Это вот кто-то прям использует? Для чего именно?
     
     
  • 3.95, Аноним (91), 17:17, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не понял - проходи мимо. Для меня да, это уберфича.
     
     
  • 4.101, Аноним (98), 03:09, 08/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так что делает эта уберфича?

    Я поначалу подумал что это



    o---o---o---o---o  master
         \
          o---o---o  subsystem
                   \
                    *---*---*  topic



    git switch subsystem
    git rebase --update-refs master

    и получим



    o---o---o---o---o  master
                     \
                      o---o---o  subsystem
                               \
                                *---*---*  topic



    Но, похоже, это не так.
    У меня получается



    o---o---o---o---o  master
         \           \
          o---o---o   o---o---o  subsystem
                   \
                    *---*---*  topic




     

  • 1.52, Neon (??), 21:08, 04/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Никогда не понимал прелестей Git'a. Излишне замудренная система. Всегда в команде хватало для совместной разработки SVN. Просто и сердито. И никаких извращений от Git'a ни разу не потребовались

     
     
  • 2.59, Аноним (58), 23:56, 04/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    До тех пор пока он не сломался и 50 программистов целый день ничего не делали. Вся работа встала.

    Сразу после этого начался процесс внедрения git.

     
  • 2.82, Аристарх (??), 15:11, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну не, прегибаешь! Гит (а правильнее говорить Mercurial :) ) нужен как средство НЕЗАВИСИМОЙ разработки. Нередко бывает так, что есть общий файл (к примеру, константы для множества проектов). Ты туда что-то полез добавлять - файл заблокирован! А кто-то свою константу хочет добавить - и понеслись "совещания"!

    DVCS - вещь весьма нужная, но отпугивает излишней сложностью процессов. А в случае GIT - ещё и череззадницу сделанными командами, имена которых вообще не соотносятся с действиями.
    Людям нужна очень простая DVCS, чтоб буквально 5-10 команд и возможность РУЧНОГО управления всеми ветками/версиями. Если древо версий можно легко починить руками, ей не страшны никакие новички со "страшными командами". :)

     

  • 1.65, Аноним (65), 00:57, 05/10/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А скажите, в чём сермяжная правда переизобретать coreutils в git?
     
     
  • 2.66, Аноним (58), 02:23, 05/10/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы он автоматически работал с системой контроля версий.

    Например с .gitignore.
    Или мог показать файлы конкретного коммита с помощью git-ls.

     
  • 2.83, Аристарх (??), 15:14, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Линус пухнет со скуки - git пухнет от линусовых "нововведений". Ждём внедрения systemd внутрь git. На Расте, разумеется. гb|гb|
     
     
  • 3.90, Аноним (102), 23:30, 06/10/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На Расте, разумеется.

    Всё лишь бы не учить функциональное программирование на Clojure.

     
     
  • 4.96, Аноним (91), 17:18, 07/10/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Функциональное программирование можно учить на нормальных языках, то же расте. Его точно не надо учить на выродочных лишпах.
     

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



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

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