2 ms·

It's been there for a long time AFAIK... not sure what the use case is though. (I guess if they're all non-conflicting then it's chill?)

amelius 8y ago
Perhaps the use-case is "consensus". I.e., when you have a 66-way merge and 50 of those say "x=0;" and 16 of those say "x=1;", then it can pick the one with the most consensus, i.e. "x=0;". Or something like that ... EDIT: of course using a special flag, otherwise indeed it could lead to problems.
- mehrdadn 8y ago
  I'd wager it's just to make life a bit easier, not because of any technical advantages... i.e. so that they don't have to sign off on 66+ commits for a 66-commit merge.
- et2o 8y ago
  What is the likelihood that the commits making up the different versions would be byte-for-byte identical, however?
  - amelius 8y ago
    They don't need to be identical. You could use the same kind of algorithms as bioinformaticians use to merge multiple different DNA sequences (which can be of different length). https://en.wikipedia.org/wiki/Edit_distance https://en.wikipedia.org/wiki/Edit_distance https://en.wikipedia.org/wiki/Consensus_sequence https://en.wikipedia.org/wiki/Consensus_sequence
- tomsmeding 8y ago
  If git did that automatically, without reporting a merge conflict, that would be a disaster. Suppose there were more Americans on team 1 of the Mars Climate Orbiter and more Europeans on team 2, so team 1 chose imperial units by consensus and team 2 chose metric units by consensus. That isn't going to give a stable system.
sbx320 8y ago
It allows a reduction of (useless) merge commits. Assume you have 8 different branches (without conflicts) that you need to merge. Then you can either have 8 merge commits (merged $number into master), or a single one (merged 1,2,3,4,5,6,7,8 into master). If you have no conflicts, it makes the history much cleaner without losing relevant history.

amelius 8y ago

Perhaps the use-case is "consensus". I.e., when you have a 66-way merge and 50 of those say "x=0;" and 16 of those say "x=1;", then it can pick the one with the most consensus, i.e. "x=0;". Or something like that ... EDIT: of course using a special flag, otherwise indeed it could lead to problems.

mehrdadn 8y ago
I'd wager it's just to make life a bit easier, not because of any technical advantages... i.e. so that they don't have to sign off on 66+ commits for a 66-commit merge.
et2o 8y ago
What is the likelihood that the commits making up the different versions would be byte-for-byte identical, however?
- amelius 8y ago
  They don't need to be identical. You could use the same kind of algorithms as bioinformaticians use to merge multiple different DNA sequences (which can be of different length). https://en.wikipedia.org/wiki/Edit_distance https://en.wikipedia.org/wiki/Edit_distance https://en.wikipedia.org/wiki/Consensus_sequence https://en.wikipedia.org/wiki/Consensus_sequence
tomsmeding 8y ago
If git did that automatically, without reporting a merge conflict, that would be a disaster. Suppose there were more Americans on team 1 of the Mars Climate Orbiter and more Europeans on team 2, so team 1 chose imperial units by consensus and team 2 chose metric units by consensus. That isn't going to give a stable system.

sbx320 8y ago

It allows a reduction of (useless) merge commits. Assume you have 8 different branches (without conflicts) that you need to merge. Then you can either have 8 merge commits (merged $number into master), or a single one (merged 1,2,3,4,5,6,7,8 into master). If you have no conflicts, it makes the history much cleaner without losing relevant history.