6 ms·

How do you propose that be dealt with programmatically?

by nilved 10y ago

BinaryIdiot 10y ago
To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those". At the same time adding extra smarts like that, while providing a better UX when it works, the times where it doesn't work especially if you don't notice it stopped working in a specific way...that all scares me. I'm not sure we're ready for smarts in our merging.
- 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.
- palunon 10y ago
  Git supports external merge tools (per file type too). They don't need to be packaged with the base install IMO, and git won't support every language under the sun. For example Unity3D are distributing one for their assets (which are not nice to merge as simple text)
  - BinaryIdiot 10y ago
    For sure and I didn't mean they should necessarily be packaged with the base install either (though I'd argue as long as they're developed in a way that they can be updated you could provide a better UX bundling a few most common ones in). It's certainly doable though my only worry is them being almost smart enough and making a big mistake that isn't immediately noticeable.
- deleted 10y ago
  [deleted]

How do you propose that be dealt with programmatically?

by nilved 10y ago

How do you propose that be dealt with programmatically?

To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those". At the same time adding extra smarts like that, while providing a better UX when it works, the times where it doesn't work especially if you don't notice it stopped working in a specific way...that all scares me. I'm not sure we're ready for smarts in our merging.

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.
palunon 10y ago
Git supports external merge tools (per file type too). They don't need to be packaged with the base install IMO, and git won't support every language under the sun. For example Unity3D are distributing one for their assets (which are not nice to merge as simple text)
- BinaryIdiot 10y ago
  For sure and I didn't mean they should necessarily be packaged with the base install either (though I'd argue as long as they're developed in a way that they can be updated you could provide a better UX bundling a few most common ones in). It's certainly doable though my only worry is them being almost smart enough and making a big mistake that isn't immediately noticeable.
deleted 10y ago
[deleted]