What about the safe (but complicated) diff -c by default (to prevent misinformed Use Remote/Local decisions, by default) and a "Conflicts Only" option (disabled by default) that shows the diff --cc output for those who know what they are doing? jon. On Wed, Mar 31, 2010 at 11:39 PM, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote: > Am 3/31/2010 13:12, schrieb Jon Seymour: >>> I looked at the result, but it does not convince me. In my case, I have a >>> large file that has many changes between the "maint" and "master" >>> branches. Whenever there are conflicts after merging "maint" to "master", >>> I see all these changes, and really they *are* uninteresting. >>> >> >> I think you may have missed the point of my patch. >> >> The successfully merged lines may be uninteresting from the point of >> deciding what I should *do* but they >> are highly relevant to the question of what I really, really should *not* do. > > How would you decide that if you cannot read the information that is > presented to you? > > Can you tell without thinking for 10 seconds which of these two changes is > lost if you choose "Use local version"? > > @@@ ... @@@ > x > +foo > y > @@@ ... @@@ > a > - bar > b > > Oh, it's easy for the conflicted part of the diff, which you'll see > elsewhere as well: > > @@@ ... @@@ > r > ++<<<<<<< HEAD > +foo > ++======= > + bar > ++>>>>>>> some-branch > s > > Do not forget that in a case (like mine) where the non-condensed diff is > actually huge, the conflict markers would no exactly be easy to find in > the diff. > >> If there are 100 successfully merged lines from each side of the merge >> but only 2 conflicting lines, should I >> >> a) pick the remote branch >> b) pick the local branch >> c) manually edit the conflicting line (or use a merge tool) >> >> The point of my patch it to make it much more likely that you will pick c). > > And I was saying almost the same, namely that it should not only be "much > more likely" to pick c, but to *always* pick c (by making it the only > option available). > >> In the current state, the GUI doesn't make it clear that either a) or >> b) is almost certainly a huge mistake. > > And therefore I suggest to disable these options. > >> Now, you could disable Use Remote and Use Local for all but the very >> simplest cases - but you don't need it for these >> cases. Hell, ed would do for these. > > Which are those very simplest cases that you are referring to? If you mean > modify/delete conflicts, then I indeed would like to keep the options for > them. > > That said, your earlier patch that presented the diff against HEAD was not > bad after all. > > -- Hannes > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html