Пал один из последних оплотов Mercurial (Hg)

Большинство писателей «чего-то сложнее хелловорлда» меняют проект раз в несколько месяцев и с такой проблемой просто не сталкиваются

Раз в несколько месяцев меняют проект? Вы там опечатки в документации Windows XP исправляете что ли? Или просто на расслабоне имитируете бурную деятельность перед заказчиком?

Или ты каждые 10-20 минут делаешь комит и тестируешь его на CI/CD?

Я делаю коммит, когда сделал осмысленный кусок работы. Это может быть 10 минут или 10 часов или 4 дня, всё зависит от работы. Добавил 4 новых функции в класс и тесты для них – коммит. Использовал эти функции в другом модуле для замены старой лапши, протестировал на локалхосте – коммит. Разбил переусложненный класс на два – коммит. Написал примитивную реализацию сложного алгоритма – коммит. Обнаружил, что притивная не катит, переписал на более оптимальное O() – коммит. Попутно нашел скрытый баг, мешающий моёму коду, – переключился в новую ветку, написал написал тест, написал фикс – коммит. Написал в багтрекер тикет, приложил diff (или pull request, в зависимости от принятой модели). Переключился в ветку фичи, – смерджил свою ветку с фиксом.

На следующий день я открываю лог и вижу, что было сделано. Сразу вхожу в контекст работы над фичей. Это МНЕ надо. Я не собираюсь помнить каждую запятую в коде, который я правил за предыдущую неделю. Я иногда реально не помню, какие функции я правил 2 дня назад и почему. У машины память большая, пусть она всё это сама помнит.

Еще раз: история правки незаконченных фич тебе не нужны в 99% случаев.

Нет, нужны. Ты снова рассказываешь мне, что мне что-то не нужно?

Вот для этого нужны ветки/патчи. Но тебе не нужно делать это каждый день.

Столовые приборы нужны только если еда слишком горячая. А в остальное время можно хватать еду руками. А суп можно пить прямо из кастрюли. Я отказываюсь принимать такую логику.

У вас не хватает элементарной гигиены и порядка в организации процесса. Делать работу упорядоченно – на самом деле просто и удобно. Перестаешь беспокоиться о проблемах управления кодом и просто работаешь над предметной областью. Хотя детям непривычно мыть руки перед едой, и они ноют. То же самое и со взрослыми.

А то, что ты рассказываешь, это какой-то адок из лапши и тарболов, мешающий работе.

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

Мои законченные ревизии состоят из осмысленных фрагментов работы, см. выше.

На тарбол же ж. Точно так же, как в CI указывают на ревизию в Git.

/me крутит пальцем у виска. Может мне его еще и скачать обратно предложишь?

Index, my ass. Нашел, на что жаловаться…

Я вообще 99% времени коммиты закатываю по git commit .. Именно потому что у меня коммиты чётко очерченные, мне не нужен никакой пердолинг с индексом. Написал осмысленный и компилирующийся кусок кода – закоммитил.

А, или ты под словом меняют имел в виду переключаются с проекта на проект?

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

Индекс — это фича одного git, придуманная Торвальдсом, и больше ни в одном VCS не присутствующая. Гитовые утята в 2020 году, действительно, не понимают, как может существовать VCS без индекса.

Просто, Торвальдс любит, когда можно пердолиться со внутренностями системы. Да, в BitKeeper и Mercurial есть внутренняя сущность, предсталвяющая собой правки, которые будут превращены в комиты, но они не светят эту внутреннюю сущность пользователю.

А как в Mercurial (Hg) без индекса обстоит дело с тем, когда из кучи изменений, которые ты сделал в дереве проекта, нужно закоммитить лишь некоторые, несколькими коммитами? Индекс очень удобно позволяет разрулить такие ситуации, которые весьма часто возникают. Ну а если нужно сделать коммит без индекса, то пожалуйста, вот тебе удобные alias’ы:

[alias]
    cm = commit
    cs = commit -S
    ca = commit -a

но нельзя переписывать историю ветки, нельзя менять сообщения в комитах, нельзя менять первый комит в ветке — как это позволяет делать Git.

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

Добавил 4 новых функции в класс и тесты для них – коммит. Использовал эти функции в другом модуле для замены старой лапши, протестировал на локалхосте – коммит. Разбил переусложненный класс на два – коммит

Видать, я тебя с кем-то перепутал. Здесь сложно что-то возразить, потому что я сам так делаю: внес правку, потестировал, закомитил. Это нормальный workflow. Правда, я не делаю вот так:

Написал примитивную реализацию сложного алгоритма – коммит

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

Еще раз: история правки незаконченных фич тебе не нужны в 99% случаев.

Нет, нужны. Ты снова рассказываешь мне, что мне что-то не нужно?

Да.

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

Здесь некоторые предлагают мыть приборы после каждого укуса — вдруг слюна попадет куда не надо и заразит другого человека. Мол «меня не напрягает». Нередко оказывается, что кроме комитов им особо нечем похвастаться — это примерно как профессиональные перекладыватели бумажек. Можно считать, что у меня вполен конкретный батхерт, вызванный опытом работы с подобными людьми.

А то, что ты рассказываешь, это какой-то адок из лапши и тарболов, мешающий работе

Тарболы и rsync — это отчка отсчета, по которой меряется удобство VCS. Если VCS не предоставляет упрощения работы по сравнению с этим нулем, то она не нужна.

Может мне его еще и скачать обратно предложишь?

Ну ты же его заливал? Значит, он у тебя уже есть на локалхосте. Делаешь diff, смотришь правки.

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

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

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

Кстати, я так и не понял из твоих комментариев, почему git index — плохо, а hg mq — хорошо.

Или mq тоже плохо?

В чем состоит мнение?

А как в Mercurial (Hg) без индекса обстоит дело с тем, когда из кучи изменений, которые ты сделал в дереве проекта, нужно закоммитить лишь некоторые, несколькими коммитами? Индекс очень удобно позволяет разрулить такие ситуации, которые весьма часто возникают

Зависит от инструмента и ситуации. Просто отобрать отдельные файлы из всех измененных и созданных — это еще не индекс. Идея явного индекса заключается в том, что тебе может потребоваться вносить не те файлы, которые у тебя в рабочей копии. То есть, у тебя как бы две рабочих копии, и потому шесть направлений движения информации. Вместо двух.

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

Тебе просто не нужно DVCS. Как и многим людям. бездумно применяющим Git «потому что все так делают». Ты в принципе не можешь поменять сообщение коммита, потому что репа у другого человека на локалхосте и доступа к ней ты не имеешь. Поменять сообщение в данном случае — значит рассинхронизировать историю, а если он сделает синхронизацию, то можно очень удивить владельца рассинхронизированного репозитория. Сообщения комита в чем-то сродни коментам в коде, но сегодня ты хочешь поправить опечатку в сообщении, а завтра у тебя тут неправильный коментарий в коде, который вводит в заблуждение — и вот ты уже совсем забыл про смысл DVCS.

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

Я делаю это же через stash. Потом применяю к нужной мне ревизии. Причем, stash создаю только тогда, когда понимаю, что правки затянулись и сразу закомитить не получится.

Кстати, я так и не понял из твоих комментариев, почему git index — плохо, а hg mq — хорошо.
Или mq тоже плохо?

Это разные инструменты. MQ — это временные ветки здорового человека. Которые можно реорганизовывать, перебазировать на разные базовые ревизии, и в том числе применять сразу к нескольким веткам. То есть, неограниченная возможность перекраивания своей «истории», которая не происходит в ущерб идее вечной неизменной публичной истории DVCS, поскольку в публику уходит только итоговая чистовая версия.

Понятно, что разные. Просто тебя закусил index как добавляющий дополнительные flow.

А что в hg этих вариантов flow в разы больше, тебя не смущает. Можно еще про bookmarks вспомнить.

Неверно, что гит сложный. Он как раз концептуально очень простой. А hg напоминает Windows: внезапно оказывается, что у тебя есть еще и вот это и вон то. При этом 99% пользователей реально не понимают, как этим пользоваться за пределами простого commit и push-pull.

может существовать VCS без индекса

Может. Но будет ли это гит(или его эквивалент по устройству)?

но нельзя переписывать историю

Это уже культ карго. История для историков и vcs для кодеров. А не код для vcs и vcs для историков.

Просто отобрать отдельные файлы из всех измененных и созданных — это еще не индекс.

Так в индекс Git’а ты вполне себе можешь добавлять не файлы, а патчсеты из изменённых файлов. При этом аккуратно их разбивать, чтобы в коммит ушли только нужные правки. Удобно, из коробки.

Тебе просто не нужно DVCS. Как и многим людям. бездумно применяющим Git «потому что все так делают».

DVCS это + к надёжности репозитория. Все VCS не являющиеся DVCS, потихоньку отмирают, вроде svn, cvs и прочего ужаса.

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

Да это понятно конечно же. Можно было бы накостылять такую систему «сбоку», чтобы история синхронизировалась отдельно при git pull/push, раздать те же права доступа на редактирование истории и т. д. И всё это снова направляет DVCS в централизованное состояние. И поэтому это неоправдано. Как показала практика, редактирование истории довольно редкий use case. А приступы внезапного перфекционизма – та я ещё дрянь.

У меня к Git’у кроме вот этой вот несбыточной хотелки с лёгкой правкой истории, имеются ещё две, которые я бы хотел, чтобы когда-нибудь реализовали.

Вторая заключается в том, чтобы при git clone/pull/fetch и прочих сетевых обращений работала «докачка» и проверка целостности. На нестабильных сетевых соединениях клонирование репозитория это сущий ад. Имел счастье несколько лет назад пару недель поработать на GPRS/EDGE соединении (дача), клонировал репозитории раза с 10-го.

Ну а третья – возможность добавления в Git пустых каталогов, это очень полезно для обозначения структуры проекта. Файлики .blank и пр. считаю костыльным решением.

Неверно, что гит сложный. Он как раз концептуально очень простой. А hg напоминает Windows: внезапно оказывается, что у тебя есть еще и вот это и вон то. При этом 99% пользователей реально не понимают, как этим пользоваться за пределами простого commit и push-pull

Ты слишком абстракно рассуждаешь, я бы советовал вернуться к конкретике. «Простые» — это diff/patch/rsync, но тебе они почему-то не нравятся.

Это уже культ карго. История для историков и vcs для кодеров. А не код для vcs и vcs для историков

Это не абстрактная теория для историков, а базовый принцип DVCS. Примерно как нельзя изменить содержимое торента или нельзя изменить транзакцию битка. Не потому, что так вот авторам захотелось, а потому, что более одного узла содержит копию истории, причем, между этими узлами слабая синхронизация. Если ты завязываешь всю работу на один узел, то ты теряешь свою DVCS, поскольку она централизуется.

Да, в том же SVN нет фичи вроде «сохранить ветку локально, чтобы потом отправить на сервер» — она есть, например, в Perforce. Еще был SVK, но он, похоже, чуток сдох.

Так в индекс Git’а ты вполне себе можешь добавлять не файлы, а патчсеты из изменённых файлов. При этом аккуратно их разбивать, чтобы в коммит ушли только нужные правки. Удобно, из коробки

Удобно, если ты — мейнтейнер ядра линукс. И то, патчи проходят сначала ревью, а в Git такой фичи нет, потому по итогу патч — это отдельная сущность, которая импортируется в Git. Для остального есть «hg commit --interactive».

DVCS это + к надёжности репозитория. Все VCS не являющиеся DVCS, потихоньку отмирают, вроде svn, cvs и прочего ужаса

У них есть свои проблемы. CVS — да, не нужен. Но идея SVN вполне себе годная, но никто не развил ее. В итоге GitHub на самом деле стал новым SVN-ом — что я нахожу забавным.

Вторая заключается в том, чтобы при git clone/pull/fetch и прочих сетевых обращений работала «докачка» и проверка целостности. На нестабильных сетевых соединениях клонирование репозитория это сущий ад. Имел счастье несколько лет назад пару недель поработать на GPRS/EDGE соединении (дача), клонировал репозитории раза с 10-го

В Microsoft это уже поняли, но с другого конца — размеры их проектов оказались неподъемными для Git даже при высокоскоростном соединении.

В итоге GitHub на самом деле стал новым SVN-ом — что я нахожу забавным.

А я вот что забавным нахожу. С помощью Git хрен скачаешь определённую директорию из проекта. Приходится весь проект выкачивать с обрезанной или полной историей. Однако, если воспользоваться SVN-магией на GitHub’е, то директорию из репозитория можно скачать без труда:

svn export https://github.com/nzeemin/nzeemin-opensrc/trunk/dingoo/ColorLinesSdl/src ColorLinesSdl
cd ColorLinesSdl
gcc `sdl-config --cflags --libs` main.c -o Lines
./Lines

Неизвестно, правда, как долго эта фича будет в онлайне. Да и в последний Git вроде подобную возможность втянули. Но это не точно, не следил.

Может кому будет полезно.

нельзя переписывать историю ветки, нельзя менять сообщения в комитах

В mercurial ещё как можно

нельзя переписывать историю ветки, нельзя менять сообщения в комитах

В mercurial ещё как можно

Пересозданием комитов же ж.

С помощью Git хрен скачаешь определённую директорию из проекта.

Емнип, такая фича недавно появилась. До этого приходилось возиться со sparse-checkout

Чего? А в гит, ты думал, чексумма та же остаётся у коммита после, например, перестановки двух коммитов? В обоих случаях и в гит и в меркуриал коммит будет новым вместо исправленного

Емнип, такая фича недавно появилась. До этого приходилось возиться со sparse-checkout

Кто-то пользовался ей? Как выглядит?

Я пользовался. Правда не помню какие именно проблемы потом были. Использовал для выкачивания пары директорий дерева portage на телефон и отправки коммитов. Качает больше чем сами директории (история чуть качается), но меньше чем всё сразу. Надо бы новые способы поискать.

Использовал так:

Создаём каталог, переходим в него и инициализируем хранилище

mkdir <repo>
cd <repo>
git init

Добавляем настройки для включения sparseCheckout и создаём список директорий для выкачивания

git config --local core.sparseCheckout true
echo "path/to/dir1" >> .git/info/sparse-checkout
echo "path/to/dir2" >> .git/info/sparse-checkout

Добавляем удалённый репозиторий; создаём и сразу переключаемся на ветку, которую хотим скачать (называем её так же, как на удалённом сервере); скачиваем, например, последние 4 изменения и накладываем их на текущую ветку:

git remote add -t required_branch origin remote_URL
git checkout -b required_branch
git pull --depth=4

или

git remote add origin remote_URL
git checkout -b required_branch
git pull --depth=4 origin required_branch

Если не сделать переключение git checkout -b required_branch на ветку required_branch, то ветке в локальном репозитории при выполнении команды git pull будет присвоено имя master и это вызовет путаницу.

Сейчас есть опция clone --filter=sparce:path=<path> . Ей пока не пользовался.

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

я это решение нашёл в июне 2018, а git 2.17 в апреле 2018 вышел, поэтому ещё не знал о второй опции.

Если человек не понимает как работает инструмент, которым ему надо польоваться, то ему на обучение. Или вон из профессии.

Если человек не понимает как работает инструмент, которым ему надо польоваться, то ему на обучение. Или вон из профессии

Сорцы ls/cat давно читал?

Речь о принципах работы а не о деталях реализации.

мдя…

https://git-scm.com/docs/git-rev-list

Note that the form --filter=sparse:path=<path> that wants to read from an arbitrary path on the filesystem has been dropped for security reasons.

при попытке использовать

fatal: sparse:path filters support has been dropped

А вот так не смотрел?

https://stackoverflow.com/a/52269934

Там написано что недавно проверяли на GitHub’е.

from git 2.19 now works on GitHub (tested 2020-09-18, git 2.25.1)

Я вижу там фильтр --filter=blob:none для игнорирования блобов при скачивании, а -depth=1 и так полезно использовать, если ранняя история не интересна.

Но там много. Что-то другое имелось ввиду?

Команда по ссылке первая:

git clone \
>   --depth 1 \
>   --filter=blob:none \
>   --no-checkout \
>   https://github.com/cirosantilli/test-git-partial-clone \
> ;
Cloning into 'test-git-partial-clone'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Receiving objects: 100% (5/5), done.

cd test-git-partial-clone

git checkout master -- d1
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 45 bytes | 45.00 KiB/s, done.

ll
total 4
drwxrwxr-x. 2 exl exl 4096 Oct  3 18:41 d1

У меня вроде отрабатывает нормально. Вот только не знаю как там оно реально скачивается, одна директория или pack-файл с ней и потом уже из него извлекается.

В любом случае подобное не назовёшь элегантным и стройным решением. Твой вариант с --filter был бы лучше, коль он бы работал.

// git version 2.26.2, Fedora 32

Если человек не понимает как работает инструмент, которым ему надо польоваться, то ему на обучение. Или вон из профессии

Сорцы ls/cat давно читал?

Речь о принципах работы а не о деталях реализации

Ну ёлы... Качает исходники с сервера, дает возможность получить старые версии сорцов, обнаруживает твои правки в файлах, позволяет синхронизировать твои правки с правками на сервере, при этом давая возможность исправить конфликты правок. Пойдет?

А где там в clone указание скачивания директории? Я вижу только ссылку на репу.

Оно во втором вызове вроде директорию d1 качает. А не из .git разворачивает. На это как-то влияет либо --filter=blob:none, либо --no-checkout.

А в hg уж завезли нормальные ветки? С которыми можно делать что угодно, перебазировать, удалять, и прочие порой необходимые действия?

сто лет в обед как, bookmarks называется (легковесные ветки а-ля гит)

Это не базовый принцип DVCS а формальность, позволяющая договориться о конкретной версии содержимого. Проблема в том, что это не нужно софту. Мы его всё время форчим патчим мержим и иначе вандализируем. От того, что софт получил иную историю или версию или репу никто не пострадает. Разве что саппорту будет не понятно что патчить. Но знаешь, что отвечает весь софтовый саппорт на любой вопрос? «п.1 обновись». Т.о. и им история не существенна.

Если надо сделать что-то сложнее чем pull/push/commit, то приходится лезть в stackoverflow. Хотя я уже привык, и заклинания со stackoverflow выучил, но по началу было конечно не привычно, что команда reset делает 3 разных действия, а еще reset можно сделать checkout’ом, для работы с бранчами есть несколько команд с совершенно неочевидными названиями ну и т.п.

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

Ага, no-checkout, получается нужен, чтобы явно не переключался на ветку и не качал пока ничего, кроме информации о репе.

Спасибо, попробую.

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

А как еще засунуть в git ~100-1000G сорцов? Очевидно, что нужно написать свой backend, который выглядит как git только внешне. Фейсбук по тем же причинам аналогичное провернули с hg. А в Яндексе вообще не стали заморачиваться и написали морду тоже свою, так как нет никакого смысла мимикрировать по hg/git и поддерживать 100500 ненужных команд.

Написал осмысленный и компилирующийся кусок кода – закоммитил.

Вот вот. Я вообще в основном проекте на svn сижу. А что, код компилируется - коммитишь. Если не хочешь, чтобы он включался в проде, обкладываешь флагами и всё равно коммитишь. И никакого сношания с бранчами :)

ну андроид как-то с git + repo работает

Чую что со страшным геморроем. У меня как-то был проект с git + submodules. Больше не хочу такого. Кто когда и куда должен двигать ревизии сабмодулей это огромный вопрос, тут есть 100500 способов накосячить. В общем, говнище нерабочее, хуже svn.

А зачем он нужен, если GUI для Git’а обычно реализовано в той IDE, в которой ты пишешь код.

Открыл в vscode (там встроенная поддержка git) репу, доступ к которой имеется через ssh-ключ + пароль - даже синхронизировать не могу, т.к. пароль он не спрашивает никак - так и крутится попытка сделать pull. Возможно, сторонние расширения чуть круче. Пока из тех сторонних утилит, что я пытался запустить у всех какие-то проблемы если есть gpg-signature.

Это не базовый принцип DVCS а формальность, позволяющая договориться о конкретной версии содержимого. Проблема в том, что это не нужно софту

Я уже за$!#% писать, что людям не нужен DVCS. И все равно люди продолжают отвечать про использование Git в качестве централизованной репы, да еще и мне объясняют:

Пал один из последних оплотов Mercurial (Hg) (комментарий)

DVCS это + к надёжности репозитория. Все VCS не являющиеся DVCS, потихоньку отмирают, вроде svn, cvs и прочего ужаса

Пал один из последних оплотов Mercurial (Hg) (комментарий)

Похоже ты суть DCVS тоже не осилил, живешь в мире SVN.

Для 98% пользователей Git = SVN с локальным кэшированием контента. Они же будут кричать, что свн — это прошлый век, и продолжать качать каталоги с гитхапба через

svn export https://github.com/nzeemin/nzeemin-opensrc/trunk/dingoo/ColorLinesSdl/src ColorLinesSdl

Спасибо, попробую.

Всё равно это довольно неудобно в сравнении с вызовом svn export, ну хоть так.

Фейсбук по тем же причинам аналогичное провернули с hg.

Вот-вот, я сильно сомневаюсь что ванильный Mercurial (hg) на Python, да ещё и втором, адекватно прожевал бы сорцы Windows и вообще отработал в тех условиях, в которые Microsoft поставил Git. Скорее всего там сразу был бы OOM.

Направленый ациклический граф ревизий. То что изменения сохраняются в виде ченджсета для всего репозитория сразу. И все отсюда вытекающее. Отсюда, например, сразу понятно что означает rebase - всего лишь изменение родительского узла данной ревизии на другрй.