Дублирование перехватчиков git-клиента на стороне сервера
Все это связано с основной очередью. Есть 4 перестановки.
i) Последовательная очередь, отправка async: здесь задачи будут выполняться один за другим, но основной поток (эффект для пользовательского интерфейса) не будет ждать возврата
ii) Последовательная очередь , диспетчерская синхронизация: здесь задачи будут выполняться один за другим, но основной поток (эффект в пользовательском интерфейсе) покажет lag
iii) Параллельная очередь, отправка async: здесь задачи будут выполняться параллельно, а основной поток (эффект на UI) не будет ждать возврата и будет плавным.
iv) Параллельная очередь, диспетчерская синхронизация: здесь задачи будут выполняться параллельно, но основной поток (эффект для пользовательского интерфейса) будет show lag
Ваш выбор параллельной или последовательной очереди зависит от того, нужен ли вам результат предыдущей задачи для следующего. Если вы зависите от предыдущей задачи, примите очередность очередности, возьмите параллельную очередь.
И, наконец, это способ проникнуть обратно в основной поток, когда мы закончили с нашим бизнесом:
DispatchQueue.main.async {
// Do something here
}
2 ответа
Вот решение, которое работает на меня. Это действительно требует, чтобы Вы выполнили две коротких команды однажды в рамках любой копии repo.
В рамках любой копии Вашего repo, сделайте следующее:
- Копия Ваша .git/hooks папка и/или любые сценарии рычага Вы хотите использовать для .githooks. Можно выбрать другое имя папки, чем .githooks, конечно. А именно, в главной папке Вашего использования repo
$ cp-a .git/hooks .githooks
- Добавляют, что .githooks мерзавцу repo
$ добавляют, что мерзавец .githooks
$ фиксирует-m, 'добавил .githooks каталог'
Примечание, только необходимо сделать эти первые два шага однажды в любом из repos, не в каждой локальной копии.
В рамках каждой локальной копии repo Вам будет нужно к [1 119]
- Изменение конфигурация локального repo для использования .githooks вместо конфигурации мерзавца .git/hooks
$ - локальный core.hooksPath .githooks
- В этой точке, локальный repo готов начать делать .git/gitHeadInfo файл, но так еще не будет делать. Любой
- Делают фиксацию
- , Выполняют один из рычагов gitinfo2 (которые являются сценариями, в конце концов), вручную. Например,
$ .githooks/post-commit
клиентские рычаги мерзавца не выполняются на сервере - но почему нет?
Обычно Вы продвигаете к пустому repo (repo без рабочего дерева, где Вы не можете делать любую фиксацию непосредственно)
Так , фиксации серверной стороны больше об осуществлении политик, чем создание новых фиксаций.
при реальной необходимости в новом содержании, которое будет создано на стороне сервера (особенно один у Вас нет прямого управления, как GitLab.com), Вам было бы нужно:
- любой для активации некоторого рычага серверной стороны, который на данный момент только доступен в GitHub, с действия GitHub .
- или установка слушатель GitLab webhook: это, которое webhook позвонил бы (на каждое нажатие события ) Вашему слушателю, который мог в свою очередь получить последнюю историю, сделать любую модификацию, Вы нуждаетесь, создаете новую фиксацию и пододвигаете обратно.