Hacker News Reader

Comment by chavesn | Hacker News Reader

I've heard this same line of thinking many times, usually in allusion to Git but often not stated explicitly. But I've never heard a good answer to the question of how you can actually have an adequate SCM-merge unless it's language and refactoring aware (and even then...)?

Every SCM that exists will fail spectacularly at merging two refactorings that touched the same code. You simply can't solve this with software today.

Enter... merge pain.

The only real solution that doesn't involve developers avoiding refactoring unless they really need to (either because it's painful or because they don't know they should be doing it), is trunk-based development.

As a footnote, for what it's worth... multiple services with SoC is definitely a good thing, but I don't think trunk-based development precludes that.

View on HN

Every SCM that exists will fail spectacularly at merging two refactorings that touched the same code. You simply can't solve this with software today.

Same code is not supposed to be refactored twice. If it happens, a human with knowledge of the two refactors must resolve the conflict.

If there's a line of code which has been touched twice in two different refactoring efforts, I dont think its a good idea to let machine decide between them.

Unless, machine knows the exact purpose of the code. If we get to that point, I think machines will be able to write programs themselves :)

The good folks at PlasticSCM are working in the direction of smarter (language-aware) history and merges with Plastic and SemanticMerge. References:

- http://www.semanticmerge.com/ - http://herdingcode.com/herding-code-183-semantic-merge-with-...

But you are doing a merge possibly every time you push to the trunk, are you not? So if I got it right, the difference between branch based and trunk based style is how long you let your branches to develop, both in time and commits. The one extreme is a branch for the whole release and the other is a "branch" for just a one commit. Feature branches would be something in between.

Now the problem with long branches and painful merges sounds like a communication problem between the master and the branch, just at the level of the code. We know that at the level of people timely and terse communication is key to a successful project. So the same would kinda make sense at the code level too.

So, if I understand you correctly:

  1. merge conflicts are almost unavoidable
     in a non-trivial codebase
  2. resolving merge conflicts in some SCM systems
     is unreasonably difficult

I'd change 2 to "resolving merge conflicts in all SCM systems is necessarily difficult."

As far as I know there's no SCM system which can understand the /intent/ of the change and without being able to reconcile the intents of two conflicting merges there's no way of reliably merging the code (at least as far as I know).

Reply on news.ycombinator.com