4 ms·

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.c

by dabber 10y ago

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 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.

oneeyedpigeon 10y ago
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.
- evincarofautumn 10y ago
  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.
Bartweiss 10y ago
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.
lmm 10y ago
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".
- yrro 10y ago
  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.

by dabber 10y ago

oneeyedpigeon 10y ago

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.

evincarofautumn 10y ago
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.

Bartweiss 10y ago

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.

lmm 10y ago

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".

yrro 10y ago
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.