That sounds cool but also a muuuch more complex problem that merge isn't expected to solve. If merging two feature branches generated actual code that understood intent and semantically combined both features, it would be close to an AI that knows how to program. I think we know diff/merge are expected to operate on character sequences not code semantics. Merging x=1 and x=1 just gets you x=1 in any VCS. And they work just as well on files that aren't code and might not have any semantics at all.
Interestingly what you want breaks an invariant I would expect traditional merge/diff to have
diff(X, Y) = 0 => merge(X, Y) = X = Y
So what you're proposing would be a different pair of ops altogether say sdiff and smerge
> If merging two feature branches generated actual code that understood intent and semantically combined both features, it would be close to an AI that knows how to program.
agree that understanding user intent is not really feasible, unless there is a way to capture the intent of the user in some clear, machine computable way.
but, less ambitiously, taking the example of merging code for a popular programming language X: the language should have some well defined grammar, etc. maybe there's even an implementation of X's grammar in a language server we can call. It shouldn't be a blue sky AI R&D project to build a custom merge tool that is able to do a three way merge of code in language X using extra information of language X grammar or feedback from a language server. we can use the extra info to reject proposed merges that obviously don't even correspond to anything valid in X's grammar. just prune the search space down to space of possible merges that make some kind of basic sense from X language perspective. often it is likely that there's more than 1 possible merge that is also valid from an X language context, we can show all these valid merges to the user and ask the user to pick which one they intended. but we can reject the other 99% of possible merges that are valid text-level merges but break obvious mechanically testable invariants of the X programming language / X's grammar
Interestingly what you want breaks an invariant I would expect traditional merge/diff to have
diff(X, Y) = 0 => merge(X, Y) = X = Y
So what you're proposing would be a different pair of ops altogether say sdiff and smerge