Станислав Бушуев

Git поддерживает worktree -- разные ветки в разных папках из одного репозитория.
Это почти то же самое, что и отдельные клоны репозитория, но эффективнее по месту и удобнее, что не надо подтягивать историю в разных клонах отдельно.

Проблема с черри-пиками в том, что они теряют историю изменений,
вот характерный пример:
при разработке фичи разработчик натолкнулся на дефект и исправил его коммитами b1 и b2;
изменения затронули файл File A;
проблема проявилась в релизе и исправления срочно затянули в мастер черри-пиками b1' и b2';
несмотря на то, что b1, b2 и b1', b2' имеют одни и те же изменения кода,
для гита это совершенно отличные коммиты, которые не имеют никакой связи между собой;
разработчик, продолжая разработку фичи, обнаружил, что исправления в b1, b2 совершенно лишние
и проблема на самом деле в файле File B;
поэтому коммитом b3 разработчик откатывает изменения b1, b2 в файле File A и вносит необходимые изменения в File B;
после завершения разработки фичи её вливают в девелоп, куда ранее был влит мастер.
Что мы имеем в итоге в ветке девелопа? А имеем изменения одновременно в файле File A ,
которые туда попали из коммитов b1', b2' и изменения в файле File B из коммита b3.
Это проблема, так как никаких сообщений о конфликте получено не было.


Как правильно поступить в таком случае?
Собственно проблема возникла из-за того, что ветка feature это смесь двух работ: исправления ошибки и разработки фичи.
Поэтому и решение в том, чтобы выделить ветку исправления ошибки отдельно, указав git'у на это:
создаём ветку bugfix, куда черри-пикаем b1 и b2;
после этого первым же делом вливаем эту ветку в фичу, тем самым указывая git'у, что конфликт слияния в этой точке разрешён;
git о конфликте в момент слияния ничего не скажет и молча сольёт, так как файлы одинаковые, но тем не менее он там есть и именно он приводит к проблемам в предыдущем сценарии;
далее смело вливаем ветку bugfix в мастер.
Всё, после этого проблемы с этими коммитами не будет.
При вливании фичи в девелоп git верно обнаружит для файла File A общего предка и откатит в нём изменения в пользу файла File B.

У git log есть опция --grep, которая как раз для этого сделана.

Самый простой путь, наверное, в ветках tmp1 и tmp2 сделать git rebase --interactive --rebase-merges и вручную собрать нужную структуру.
См. секцию REBASING MERGES в справке у git rebase.

За формат вывода отвечает help.config.
Но в тех сборках git под Windows, что я видел, нет просмотрщиков формата man или info, поэтому по умолчанию настроен вывод в html.

Улучшить можно следующими способами:

• знанием и использованием стандартных функций
  
• проверкой результатов и обработкой ошибок
  

#include <stdio.h>
#include <string.h>

#define MAX_NUM_LENGTH 100

const char* chose(const char* left, const char* right)
{
	const size_t len_left = strlen(left);
	const size_t len_right = strlen(right);
	if (len_left > len_right)
		return left;
	if (len_right > len_left)
		return right;
	if (strcmp(left, right) < 0)
		return right;
	return left;
}

const char* get_max(const char* n1, const char* n2, const char* n3)
{
	return
	    chose(
	        chose(n1, n2),
	        chose(n2, n3));
}

int main()
{
	FILE* in = NULL;
	FILE* out = NULL;
	char n1[MAX_NUM_LENGTH + 1];
	char n2[MAX_NUM_LENGTH + 1];
	char n3[MAX_NUM_LENGTH + 1];
	in = fopen("input.txt", "r");
	if (!in) {
		perror("Cannot open file 'input.txt'");
		return 1;
	}
	if (3 != fscanf(in, "%100[0-9] %100[0-9] %100[0-9]", n1, n2, n3)) {
		perror("Wrong input format");
		fclose(in);
		return 1;
	}
	const char* max_num = get_max(n1, n2, n3);
	out = fopen("output.txt", "w");
	if (!out) {
		perror("Cannot open file 'output.txt'");
		return 1;
	}
	fprintf(out, "%s", max_num);
	fclose(in);
	fclose(out);
	return 0;
}

Я так понимаю, что это хостовая машина 64х битная?
Тогда это просто кросс-компиляция.
Глянул в Makefile, есть такой совет:
make CC=cross-gcc HOST_CC=gcc
где под cross-gcc надо указать строку запуска компилятора с целевой платформой 32 бита.

А зачем отрисовывать графики с большим количеством точек? Мы в своё время тоже столкнулись с подобной проблемой: падением производительности, но как только мы осознали, что разрешающая способность области графика просто не способна вывести их всех: т. е. например, на пиксел приходится 5-10 точек графика, то сразу нашлось и решение -- выводить не сырые данные, а с фильтрацией.
Ну и ещё, возможно, вам подойдёт этот алгоритм.

Не совсем понятна цель эмулятора. Если есть необходимость строить настраиваимую сетевую конфигурацию, то я бы попробовал посмотреть в сторону CORE, у него вроде есть API на питоне.
API сам не использовал, но эмулятор очень понравился удобством моделирования разных сетевых конфигураций.

Случаем не этот топик вспоминаете?