ThunderCat

Почему «пропали» коммиты?

Главная ошибка — использование --amend во время rebase.
Команда git commit --amend не создает новый коммит, а перезаписывает предыдущий.

Когда вы время интерактивного rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.

Как делать правильно?

Во время rebase -i вместо amend нужно:

git add <файлы> #  главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-edit

Вручную делать git commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.

Как восстановить утерянные коммиты

Git не удаляет коммиты сразу. Они остаются в репозитории и доступны в reflog — журнале ссылок.

Их можно найти так: git reflog

Затем восстановить ветку: git reset --hard <хеш_из_reflog>

Вывод

Это не баг Git, а ожидаемое поведение. Просто rebase + amend — взрывоопасная смесь, особенно если не до конца понимать, что происходит.

Неделя начинается с понедельника и идентифицируется своим порядковым номером в году. Первой календарной неделей года считают первую неделю, содержащую первый четверг текущего года. Последней календарной неделей календарного года считают неделю, которая предшествует первой календарной неделе следующего года. ISO 8601.
Соответственно, 2024-12-29 - воскресенье, последний день последней, 52-й недели года.
2024-12-30 - понедельник, входящий в неделю, где четвергом является 2025-01-02, то есть в первую неделю 2025 года.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share/phpmyadmin;

Путь к файлу формируется путём простого добавления URI к значению директивы root.

URI = /phpmyadmin/index.php
root = /usr/share/phpmyadmin

В итоге nginx будет искать файл /usr/share/phpmyadmin/phpmyadmin/index.php

Если в root убрать лишний /phpmyadmin.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share;

nginx будет искать файл /usr/share/phpmyadmin/index.php

Стоит использовать те фреймворки, которые вы знаете, а то будет мало пользы

Коротко - потому что IEEE 754

Выполняет он математические операции правильно, но некоторые числа компьютер просто не способен представить со 100% точностью, тк для них нужно было бы бесконечное количество памяти.

Точно также, как мы не можем записать все цифры числа 1/3 в десятичной системе, точно также и компьютер иногда не может записать все цифры в двоичной.

Если ты работаешь с деньгами, то тогда используй то, что делают все банки - представляй суммы денег не как дробные числа, а как целые. Например место 1.5 рублей записывай как 150 копеек. Запятую добавишь при выводе человеку.
btw тут в комментах пишут, что для денег тоже есть паттерн по-лучше конкретно для php.

Если при делении у тебя получилось дробное количество копеек - округляй так, как велит закон.

Если ты делаешь какие-то математические вычисления - возможно тебе нужны рациональные числа.
Не знаю, что обычно для этого в пхп используют, но нагуглил https://github.com/webgriffe/rational
https://github.com/markrogoyski/math-php

Но в случае с целыми числами ты всё равно можешь упереться в ограничение на максимальное число, а в случае с рациональными числами ты получишь очень сильную просадку в производительности.

Если тебе критически важна скорость, а точность - не так важна, то оставайся на IEEE754 и просто округляй то N значимых цифр (обычно больше 5 цифр мало кому нужно)

Потому что типом данных double нет возможности представить число 0.58. Поэтому компьютер берёт наиболее близкое к 0.58 число, которое double может выразить.

Если вам нужны точные вычисления, то следует воспользоваться специальными функциями:

$format = bcdiv("580000000", "1000000000", 2); // "0.58"

var_dump(bcmul($format, "100")); // string(2) "58"

Существует даже специальный сайт, рассказывающий о данной особенности математики чисел с плавающей запятой: https://0.30000000000000004.com/

Проблем с временными зонами вообще не будет, если их представление выдавить максимально ближе к модели представления данных на интерфейсе пользователя.
Нужно конвертировать в строку только непосредственно перед отрисовкой дату и время из UTC, и обратно загонять время в UTC, если забираете пользовательский ввод.
Весь бек должен работать в одной временной зоне, а от пользователя знать, что он в такой-то временной зоне, только в контексте сессионной переменной, если это необходимо.

Видео в любом случае должно быть кем то сконвертировано, перед отправкой клиенту, варианты:
- Либо множество заранее подготовленных видео роликов с нужным качеством (ютуб так делает), потребуется сильно больше места на диске, но нагрузка на процессор будет сильно меньше + можно выбрать ночное время для обработки.
- Либо сервер, который будет конвертировать видео в реальном времени, но нагрузка на процессор будет сильно больше.

Угу. Сначала понаставим @, чтобы скрыть все ошибки, а потом будем голову ломать, почему ничего не работает и ошибок не показывает.

А вообще, это делается в одну строку.

file_put_contents($outfilename, str_replace('Российский рубль', 'RUB', file_get_contents($infilename)));

Или проще сделать наоборот: показывать код на мобильном устройстве, а на ТВ вводить?

Для пользователя проще вводить что-либо на телефоне, а не на телевизоре.

В общем-то такой способ входа не только на телевизорах и yt практикуется. Такое есть ещё у Microsoft и Github при использовании oauth, например. Ещё видел такое у samsung на телевизорах/мониторах и у nintendo на свиче

Смысл такой:
1. Клиент инициирует процесс аутентификации запросом к серверу аутентификации и просит, чтобы аутентификация происходила на другом клиенте. (при этом передаётся clientid / client secret просто чтобы понять, что за приложение этот запрос инициировало).

2. Сервер генерирует какой-то уникальный идентификатор для этого запроса с некоторым временем жизни (обычно не больше 30 минут). И передаёт его клиенту в ответе на запрос.

3. Клиент показывает пользователю:
1) qr-код с ссылкой для аутентификации, где уже зашит этот id
2) ссылку в виде текста
3) этот id, если вдруг его придётся вводить руками

4. Пользователь переходит в итоге по ссылке и опционально вводит этот id. Дальше идёт обычная oauth аутентификация, только без коллбэка (в конце, вместо коллбэка просто страничка аля "всё готово, страницу можно закрыть")

5. Параллельно с этим клиент в фоне опрашивает сервер аутентификации о том, прошла ли аутентификация (просто периодические запросы раз в n секунд, long polling, sse, websocket - не важно). В один прекрасный момент сервер сообщит, что аутентификация прошла и передаст твои обычные токены (обычно пару access/refresh)