Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Again, good eyes.  I think the two lines should go; my fault at cdb22c4
> (Merge branch 'jc/better-conflict-resolution' into next, 2008-09-02).

Hmm, I am somewhat unhappy.  If you run:

	$ git checkout cdb22c4^
        $ git merge cdb22c4^2
	$ git checkout --conflict=diff3 builtin-checkout.c

and look at builtin-checkout.c.  You will find this:

<<<<<<< ours
	/* --track without -b should DWIM */
	if (0 < opts.track && !opts.new_branch) {
		const char *argv0 = argv[0];
	...
		opts.new_branch = argv0 + 1;
	}

	if (opts.track == BRANCH_TRACK_UNSPECIFIED)
		opts.track = git_branch_track;
|||||||
	if (!opts.new_branch && (opts.track != git_branch_track))
		die("git checkout: --track and --no-track require -b");
=======
	if (conflict_style) {
		opts.merge = 1; /* implied */
		git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
	}

	if (!opts.new_branch && (opts.track != git_branch_track))
		die("git checkout: --track and --no-track require -b");
>>>>>>> theirs

The two lines in the middle was from the common ancestor, which was not
touched by the merged branch (that added the "if (conflict_style) {}"
block) and was lost by a rewrite in "ours".

However, the usual simplified merge shows this (run "git checkout --merge
builtin-checkout.c" if you have done the above):

<<<<<<< ours
	/* --track without -b should DWIM */
	if (0 < opts.track && !opts.new_branch) {
		const char *argv0 = argv[0];
	...
		opts.new_branch = argv0 + 1;
	}

	if (opts.track == BRANCH_TRACK_UNSPECIFIED)
		opts.track = git_branch_track;
=======
	if (conflict_style) {
		opts.merge = 1; /* implied */
		git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
	}

	if (!opts.new_branch && (opts.track != git_branch_track))
		die("git checkout: --track and --no-track require -b");
>>>>>>> theirs

Removing the two lines from the simplified "theirs" is not what I would
suggest (it would be actively wrong), but I wonder if we can do something
clever to help users with a merge like this.