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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2008-10-19 at 15:52 -0700, Junio C Hamano wrote:
> 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.

IMHO, the solution is just to use diff3 style.  I never understood how I
was supposed to intuit the correct result of a merge from the two sides
without seeing the common ancestor, so I am glad to have the diff3 style
working now.

Matt

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux