5 ms·

Were a lot of programmers really hung up on this idea of having increasingly smart merge algorithms back then? What Linus says seems self-evident to me: if the

Were a lot of programmers really hung up on this idea of having increasingly smart merge algorithms back then? What Linus says seems self-evident to me: if there's even a whiff of a conflict, I want it to be shown to me so I can make a human decision about it. A merge algorithm smart enough to resolve every case is easily proven to be impossible by the fact that it's possible for branches to merge cleanly with no conflict, and yet still have a logical conflict due to some implicit contract that was broken. These are the nastiest regressions to find, and one reason I insist on rebasing before merging topic branches, because then at least git-bisect will tell you where the implicit contract was broken precisely on the second-rebased-and-merged branch. Smarter merge algorithms would just paper over more problems and so you quickly hit diminishing and then negative returns by trying to be too clever.

gcp 10y ago
You can still verify the result of an automatic merge. It's simpler to mark a suggestion "y" than to resolve conflicts that could be solved automatically by hand. So I don't think this reasoning holds any ground whatsoever.
- andrewflnr 10y ago
  You're not actually contradicting GP. Marking a suggestion "y" is still making a human decision, just with really good auto-complete.
  - gcp 10y ago
    Look into the actual posts, it was used as an argument to dismiss smarter merge algorithms which is of course the smarter auto-complete part.
    - andrewflnr 10y ago
      What they're actually objecting to of the idea of not having a human in the loop. I suspect if you pitched these smart merge algorithms from the "click to accept auto merge" angle, they wouldn't have much of a problem. Instead they seem to be pushed as a way of avoiding interaction.
- posterboy 10y ago
  >that could be solved automatically by hand. looks like you should have had a merge conflict in that sentence /s
  - gcp 10y ago
    Add a comma before "by hand" and it'll make sense.
    - posterboy 10y ago
      Nah, I'm not sure the comma is grammatical, might actually make the last part a contradicting enumeration. The blame is on me, I quoted out of context and was a bit on the slow side understanding. The sentence is just not written well, too. On topic however, missing one such conflict is easier, if you have to spot it after the damage is done, instead of having to think about it yourself beforehand, no?
nirvdrum 10y ago
I'm not sure this is entirely fair. I've run into a fair number of merges where git couldn't resolve the conflict but meld or p4merge was able to do it trivially. If git were able to better deal with these, I don't think anyone would question it. I suspect over time that git probably has gotten smarter with merges. I surveyed a fair number of DVCS systems in the run-up to git. I'm hardly an expert, but gracefully dealing with merge conflicts was indeed something system authors were investigating. Darcs went so far as to have a formal theory of patch management [1], which guaranteed never to have a conflict (unfortunately, running the proof engine could take unduly long and in some cases, may never complete). Anyway, I think it's a tricky balance to strike. You're right that if the SCM resolves the conflict improperly and introduces a logic error, that's really tedious to track down. However, I've encountered far too many cases of bad rebases or merges resolved incorrectly by humans as well. Sometimes it's a small change the developer didn't pick up in line that was edited by both. Sometimes it was a lack of understanding of incoming changes. Sometimes it was just a battle lost to the merge tool (e.g., seeing "<<<<<<<" in source files). In all those situations, I long for a smarter merge tool. [1] -- https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...

gcp 10y ago

You can still verify the result of an automatic merge. It's simpler to mark a suggestion "y" than to resolve conflicts that could be solved automatically by hand. So I don't think this reasoning holds any ground whatsoever.

andrewflnr 10y ago
You're not actually contradicting GP. Marking a suggestion "y" is still making a human decision, just with really good auto-complete.
- gcp 10y ago
  Look into the actual posts, it was used as an argument to dismiss smarter merge algorithms which is of course the smarter auto-complete part.
  - andrewflnr 10y ago
    What they're actually objecting to of the idea of not having a human in the loop. I suspect if you pitched these smart merge algorithms from the "click to accept auto merge" angle, they wouldn't have much of a problem. Instead they seem to be pushed as a way of avoiding interaction.
posterboy 10y ago
>that could be solved automatically by hand. looks like you should have had a merge conflict in that sentence /s
- gcp 10y ago
  Add a comma before "by hand" and it'll make sense.
  - posterboy 10y ago
    Nah, I'm not sure the comma is grammatical, might actually make the last part a contradicting enumeration. The blame is on me, I quoted out of context and was a bit on the slow side understanding. The sentence is just not written well, too. On topic however, missing one such conflict is easier, if you have to spot it after the damage is done, instead of having to think about it yourself beforehand, no?

nirvdrum 10y ago

I'm not sure this is entirely fair. I've run into a fair number of merges where git couldn't resolve the conflict but meld or p4merge was able to do it trivially. If git were able to better deal with these, I don't think anyone would question it. I suspect over time that git probably has gotten smarter with merges. I surveyed a fair number of DVCS systems in the run-up to git. I'm hardly an expert, but gracefully dealing with merge conflicts was indeed something system authors were investigating. Darcs went so far as to have a formal theory of patch management [1], which guaranteed never to have a conflict (unfortunately, running the proof engine could take unduly long and in some cases, may never complete). Anyway, I think it's a tricky balance to strike. You're right that if the SCM resolves the conflict improperly and introduces a logic error, that's really tedious to track down. However, I've encountered far too many cases of bad rebases or merges resolved incorrectly by humans as well. Sometimes it's a small change the developer didn't pick up in line that was edited by both. Sometimes it was a lack of understanding of incoming changes. Sometimes it was just a battle lost to the merge tool (e.g., seeing "<<<<<<<" in source files). In all those situations, I long for a smarter merge tool. [1] -- https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...