Any branch you push to will be remembered and you accidentally could bush to a wrong branch next time, if e.g. you need to push a branch somewhere only once and then push to the upstream/tracked branch again. The better approach is to set defaults. It is tracked branch by default, but if it does not work - configure git accordingly.
А так есть опасность напушить в мастер. Пушить в другую ветку те самые коммиты не приходилось. Вдруг что, делалась отдельная локальная ветка.
REPLACE
Да, были какие-то файлы помимо *.ram, OPTIMIZE как раз убрал эти файлы.
Но сам *.ram файл не меняется в размерах и больше раза в 2,5 от нового индекса за 3-6 месяцев.
Делал TRUNCATE и заново заполнял индекс, таким образом удавалось отвоевать место.
Правда, там места несколько десятков мегабайт.
При REPLACE каждый день меняется на самом деле одно поле (расчитанная сортировка, из-за лимита на количество полей в сортировке)
Реже добавляются массово новые поля в индекс.
Какой принцип работы автокеширования?
cron?
Кроме W3 Total Cache
но на других страницах, куда могут быть подгружены эти записи, например, на главную, кеш обновлен не будет, а соответственно, добавленная или измененная запись там не появятся ровно до тех пор, пока не истечет время жизни предыдущего кеша
Это решается другими плагинами? Если да, то как
Также укажем значения «Максимальное время жизни кэшированых объектов» и «Период удаления устаревшего кэша»
Как это реализовано?
Тем не менее вторую проблему (долгая загрузка страниц в период обновления кеша) решить невозможно
Он что, сначала удаляет кеш, а потом заполняет?
чтобы кеш обновлялся не по таймеру, а только при внесении изменений
Кто бы перевел всю статью на OWASP, было бы круто
А если бы цены упали, то что?
Ну не может же постоянно бешено расти. Инвесторы какие-то непонятно чем думающие. Хотя там малая ж часть акций торгуется на бирже.
Выросли цены - акции упали. Логично.
Квантовые вычисления - магия 21 века?
Некоторые почты сами загружают рисунки и отдают с сервера почтовика.
Куда идем?
Оттуда:
А так есть опасность напушить в мастер. Пушить в другую ветку те самые коммиты не приходилось. Вдруг что, делалась отдельная локальная ветка.
Сделали бы настройку.
Сохраняются ли удаленные ветки в которые пушил с локальной? А то там постоянно master (или другая ветка, с которой делал checkout)? В 2016 сохраняло.
Также в 2021.2 checkout new branch не сохраняет ветку, с которой потом подтягивать изменения через <Ctrl> + <T>. Починили?
Очень неудобно.
Может колбэк?
При этом последователи догм очень агрессивны.
Подавать встречное уведомление
https://support.google.com/legal/contact/lr_counternotice?product=websearch&hl=ru
А разве эти абузы кто-то проверяет, а не робот?
Их часто даже робот не проверяет.
Льются жалобы на никогда несуществовавшие страницы.
А как оно работает со слияниями?
Оно найдет коммит, который входит в слияние?
Но это ненадежный показатель работы-неработы.
Или оно будет смотреть на коммиты слияний?
А потом уже как-то искать среди коммитов данного слияния.
То есть вопрос в том, как сортируются коммиты.
Почему 1х-картинки на ретине выглядят как дерьмо?
На не-ретине с бОльшим физичиским размером выглядит же нормально.
И сколько нужно было заплатить налогов?
А если бы он не вышел из гражданства, то и налоги не нужно было бы платить?
Да, были какие-то файлы помимо *.ram, OPTIMIZE как раз убрал эти файлы.
Но сам *.ram файл не меняется в размерах и больше раза в 2,5 от нового индекса за 3-6 месяцев.
Делал TRUNCATE и заново заполнял индекс, таким образом удавалось отвоевать место.
Правда, там места несколько десятков мегабайт.
При REPLACE каждый день меняется на самом деле одно поле (расчитанная сортировка, из-за лимита на количество полей в сортировке)
Реже добавляются массово новые поля в индекс.
cron?
Кроме W3 Total Cache
Это решается другими плагинами? Если да, то как
Как это реализовано?
Он что, сначала удаляет кеш, а потом заполняет?
Как это реализовано?
Конфликты решаются в отдельном коммите или как?