Only RK

Price: 300000

Number of applications: 0

Decision acceptance deadline

22.12.25 (inclusive)

Form of award

Monetary

Product status

MVP

Task type

ICT tasks

Сфера применения

Media sphere

Область задачи

Smart Field Information Systems

Type of product

Software/ IS,

Mobile app

Problem description

Let's consider the basic version of the program P₀ and two branches of changes p₁ and p₂. The semantic requirement for the result M = Merge(p₁, p₂): 1) for all valid inputs x, the behavior of M(x) is consistent with p₁(x) and p₂(x) in terms of already implemented features; 2) no branch loses its fixes; 3) Merge is deterministic and completes in a finite time. To prove that such a problem has no solution in the general case, it suffices to note that we essentially need to solve the program equivalence problem: to verify that M(x) and P₁(x) behave identically for all inputs x in the domain where the branch p₁ does not affect the changes in p₂. The equivalence of arbitrary programs in Turing‑complete languages is a classic example of an unsolvable problem.

Expected effect

The task of "a universal semantic merge that always produces the correct result" is generally unsolvable. You can build: • practical heuristic merge engines for specific languages and templates; • formal verification systems for narrow domains; • merge+testing hybrids. But the formulation in which the algorithm is required to provide absolute guarantees for any code in the repository contradicts the fundamental limitations of computability theory.

Full name of responsible person

Sergeev I.A.

Purpose and description of task (project)

The customer has a monorepository with mobile and server components (Kotlin, Swift, Go, TypeScript). The number of parallel feature branches exceeds 50, and manual conflict resolution takes weeks. A requirement was formulated: to design a semantic merge system that: • always generates the correct merged version or explicitly refuses to merge; • in case of a successful merge, guarantees the preservation of behavioral equivalence with respect to both branches (none of the existing functionality breaks); • works for any project in the repository without custom rules. In other words, an "automatic engine without surprises" was expected, which removes the issue of manual conflicts in principle.

Note

Examples and solution ideas are needed to continue the dialogue.