Johannes Sixt [off-list ref] writes:
But I would estimate that most conflicts (in absolute number among all
developers using Git) arise during rebase operations and cherry-picking,
i.e., while one is working on their own code. In such sitations, the
simpler conflict markup is sufficient, because one knows the background
and reason of the conflicts.
"rebase -i" to reorganize one's own series would be a prime example
of "conflicts you need to resolve in code that is purely your own
and nobody else's", and cherry-picking used while reorganizing one's
own series falls into the same category. I agree that a simpler
markup would be more appropriate in such cases.
Rebasing to catch up with updated upstream is a different story,
though. The same for cherry-picking an earlier change to an updated
upstream.
Am 11.06.21 um 08:43 schrieb Junio C Hamano:
Johannes Sixt [off-list ref] writes:
quoted
But I would estimate that most conflicts (in absolute number among all
developers using Git) arise during rebase operations and cherry-picking,
i.e., while one is working on their own code. In such sitations, the
simpler conflict markup is sufficient, because one knows the background
and reason of the conflicts.
"rebase -i" to reorganize one's own series would be a prime example
of "conflicts you need to resolve in code that is purely your own
and nobody else's", and cherry-picking used while reorganizing one's
own series falls into the same category. I agree that a simpler
markup would be more appropriate in such cases.
Rebasing to catch up with updated upstream is a different story,
though. The same for cherry-picking an earlier change to an updated
upstream.
I've reflected on this a bit more as well. I've forgotten about the
"catch up with someone else" case. That is certainly helped by diff3
style. I retract my opposition and am now neutral to a potential change
of default. (I still don't endorse it because it upsets my workflow.)
The case that inner conflicts are presented sub-optimally under diff3
remains, though.
-- Hannes
Johannes Sixt wrote:
Am 11.06.21 um 08:43 schrieb Junio C Hamano:
quoted
Rebasing to catch up with updated upstream is a different story,
though. The same for cherry-picking an earlier change to an updated
upstream.
I've reflected on this a bit more as well. I've forgotten about the
"catch up with someone else" case. That is certainly helped by diff3
style. I retract my opposition and am now neutral to a potential change
of default. (I still don't endorse it because it upsets my workflow.)
All right. Fortunately we have a configuration for that.
The case that inner conflicts are presented sub-optimally under diff3
remains, though.
Indeed, and that's something that we should consider fixing, but it's
not necessarily a roadblocker since apparently many developers have been
able to live with these sub-optimal diff3 inner conflicts.
Personally I have never experienced what you posted, so maybe there's
something else happening behind the scenes.
Maybe merge-ort changed something.
--
Felipe Contreras
Am 11.06.21 um 16:25 schrieb Felipe Contreras:
Personally I have never experienced what you posted, so maybe there's
something else happening behind the scenes.
I have to do a lot of criss-cross merges lately.
Maybe merge-ort changed something.
It produces the same result.
-- Hannes