Hacker News Reader

Comment by dabber | Hacker News Reader

I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]:

git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html

"it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you."

[1] This isn't explicitly against the rules but if it's in bad taste I'll happily remove it.

View on HN

That's good if the exact same conflict reoccurs, but how often does that happen? What would be far better would be a syntax-aware version control system that knows about HTML attributes and understands how to combine two separate additions of HTML attributes.

That would be an improvement, although you’d still need human intervention sometimes. Even structurally sound merges can produce semantically wrong results, because diffs aren’t enough to reconstruct a correct history in all cases.

This is great, I appreciate you putting it here. I have a conflict pattern that comes up with enormous frequency at work, and for various reasons solving it somewhere other than the merge is not a great plan. It's always the same solution, though, and I could even predict it and flag for it in the commit message.

This seems like exactly the answer to that.

rerere is dangerous and not the solution. What I want is language-aware merge that can do things like "both these changes are just adding imports, adding in either order is fine" or "this change has added a parameter and this change has reformatted this line, I can add the parameter to the reformatted line".

ISTR darcs had something like this feature, but not as advanced as your idea. One of its types of patches was 'word substution', but you could imagine an 'add import' patch type.

Reply on news.ycombinator.com