Vitsliputsli

Если бы вы привели пример, что было и что стало, можно было бы сказать точно. Но скорее всего у вас было различие на один коммит и при мерже использовалась политика fast-forward, т.е. просто скопирован коммит из одной ветки в другую. Используйте опцию --no-ff, если не хотите подобного поведения.

7.3

Не объявлены переменные $connection и $query_db_bot_1.

Столько всего написали, и только один человек отметил, что не стоит путать сильную (в неправильном переводе "строгая") типизацию со статической.
В PHP динамическая типизация, это преимущество данного языка, т.к. не нужно писать дополнительный код для обработки разных типов. В PHP даже нет классической перегрузки, т.к. она там попросту не нужна. Но динамическая типизация в PHP ни разу не отменяет возможности работать с типами, и хороший программист так и делает.
Статически типизированные языки делятся на языки с сильной типизацией, например Java, и слабой типизацией, например Си. Сильная типизация это преимущество Java, как уже писали это облегчает отлов ошибок. Слабая типизация это преимущество Си, т.к. позволяет более гибко работать с данными, что повышает производительность.
Т.е. для каждого языка своя типизация в зависимости от направления этого языка, а все восторги у тех, кто не понимает что нет "серебренной пули", универсального решения на все случаи жизни, и всегда приобретая, чем-то жертвуешь. Заметьте, как много писали про компилятор и сильную типизацию, но по факту, интерпретирующий язык Java использует сильную типизацию, а компилирующий язык Си использует слабую типизацию.

setxkbmap us

Вот пример открытия курсора и чтения из него циклом:

DELIMITER $$
 
CREATE PROCEDURE build_email_list (INOUT email_list varchar(4000))
BEGIN
 
 DECLARE v_finished INTEGER DEFAULT 0;
        DECLARE v_email varchar(100) DEFAULT "";
 
 -- declare cursor for employee email
 DEClARE email_cursor CURSOR FOR 
 SELECT email FROM employees;
 
 -- declare NOT FOUND handler
 DECLARE CONTINUE HANDLER 
        FOR NOT FOUND SET v_finished = 1;
 
 OPEN email_cursor;
 
 get_email: LOOP
 
 FETCH email_cursor INTO v_email;
 
 IF v_finished = 1 THEN 
 LEAVE get_email;
 END IF;
 
 -- build email list
 SET email_list = CONCAT(v_email,";",email_list);
 
 END LOOP get_email;
 
 CLOSE email_cursor;
 
END$$
 
DELIMITER ;

Подробнее в документации.

Подскажите, на сколько это правильно? На сколько это целесообразно?

А что именно сейчас смущает в существующей структуре? Исходите из того, что реально может помочь, а не то, что "правильно". Разбиение на несколько таблиц это затраты на join. Нет идеальных решений, любая оптимизация это жертвование чем-то, ради чего-то еще. Никто лучше вас не знает вашу систему, что произойдет после преобразований? Насколько усложнятся или упростятся запросы к БД, как по производительности, так и по читаемости?
Как вы хотите представить эти данные в новой таблице? Attribute-Entity-Value? Если да, то прикиньте насколько усложнится система и отяжелеют запросы. "Счетчиков будет гораздо больше 2," это сколько? 10-20? Тогда даже не стоит заморачиваться, если больше 100, тогда, да, можно уже сейчас начать изменять струкутуру.

По учебнику Трепачева кстати, да и везде стоит сначала session_start(), и это должно быть правильно.

А вы читали в этом учебнике кусок озаглавленный "Возможные проблемы"? Не то, чтобы мне понравился этот учебник, скорее наоборот, но просто интересно, в общем, перечитайте.

На сервер нужно загружать открытый ключ, вы же пытаетесь загрузить отпечаток ключа.

*/10 * * * * /func1
5,25,45 * * * * /func2