Size: a a a

2019 October 10

S

Stefan in DevOps
я другой серт тестил
источник

S

Stefan in DevOps
госпадибожемой
источник

S

Stefan in DevOps
вопрос закрыт, всем спасибо
источник

b

bama^boy in DevOps
источник

N

Navern in DevOps
источник

N

Navern in DevOps
каждый раз когда в чатике помогают написать баш однострочник:)
источник

S

Stefan in DevOps
Navern
каждый раз когда в чатике помогают написать баш однострочник:)
ну мистабнул по названию, с кем не бывает😐
источник

b

bama^boy in DevOps
Navern
каждый раз когда в чатике помогают написать баш однострочник:)
да, лучше расскажите, как вы service mesh организовываете без kube-proxy и istio
источник

b

bama^boy in DevOps
какие преимущества использования envoy по сравнению с consul connect?
источник

YY

Yuriy Yurov in DevOps
Всем добрый день. Не так давно я поднимал вопрос по поводу миграции репозиториев из github в AWS CodeCommit.  Полноценного решения не существовало. К счастью я реализовал полноценный скрипт который мигрирует репозитории с бранчами на лету без лишних костылей. Всем кому интересно или нужно, пользуйтесь на здоровье. https://github.com/qspors/githubtocc
источник
2019 October 11

АП

Антон [R13 🍆 Ivelok] Перетрухин in DevOps
Navern
каждый раз когда в чатике помогают написать баш однострочник:)
Главное не забыть в base64 перегнать 🌚
источник

PD

Plomipu Dmitri in DevOps
Пардон, что я вас снова беспокою, но я запутался в том же git revert <commit>. Насколько я понял данная команда может вернуть изменения проекта в том состоянии на какие указывал требуемый коммит. Но также можно задавать и диапазон коммитов для отката git revert <commit1>..<commit2>, но я не понимаю: в чём разница между ними и какая польза от диапазона вообще в этом случае, если для возвращения состояния проекта достаточно только одной ссылки на коммит по хорошему счёту ?? Или я чтото не понимаю ??
источник

N

Navern in DevOps
Plomipu Dmitri
Пардон, что я вас снова беспокою, но я запутался в том же git revert <commit>. Насколько я понял данная команда может вернуть изменения проекта в том состоянии на какие указывал требуемый коммит. Но также можно задавать и диапазон коммитов для отката git revert <commit1>..<commit2>, но я не понимаю: в чём разница между ними и какая польза от диапазона вообще в этом случае, если для возвращения состояния проекта достаточно только одной ссылки на коммит по хорошему счёту ?? Или я чтото не понимаю ??
а ты хочешь ревертить несколько коммитов?
источник

N

Navern in DevOps
вообще реверт оч редко применяемая штука
источник

PD

Plomipu Dmitri in DevOps
Navern
а ты хочешь ревертить несколько коммитов?
нет. Хочу знать, зачем это, чем полезен такой реверт с указанием диапазона вообще ??
источник

PD

Plomipu Dmitri in DevOps
Navern
вообще реверт оч редко применяемая штука
почему ?? Разве она не подходит для исправление коммитов на удалёнке ?? Ведь она очень даже кстати, если ты чтото отправил по ошибке
источник

GG

George Gaál in DevOps
Plomipu Dmitri
Пардон, что я вас снова беспокою, но я запутался в том же git revert <commit>. Насколько я понял данная команда может вернуть изменения проекта в том состоянии на какие указывал требуемый коммит. Но также можно задавать и диапазон коммитов для отката git revert <commit1>..<commit2>, но я не понимаю: в чём разница между ними и какая польза от диапазона вообще в этом случае, если для возвращения состояния проекта достаточно только одной ссылки на коммит по хорошему счёту ?? Или я чтото не понимаю ??
ты доку пробовал читать?
источник

GG

George Gaál in DevOps
очевидно из принципа работы реверта
источник

GG

George Gaál in DevOps
смотри
источник

GG

George Gaál in DevOps
по умолчанию revert создает коммит = обратная разница между текущим комитом (головой) и тем что ты укажешь
источник