Re: [PATCH v2 3/3] git-merge-one-file: revise merge error reporting

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

 



On Mon, Mar 25, 2013 at 1:17 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Subject: [PATCH] merge-one-file: force content conflict for "both side added" case

s/both side/both sides/

> Historically, we tried to be lenient to "both side added, slightly

Ditto.

> differently" case and as long as the files can be merged using a
> made-up common ancestor cleanly, since f7d24bbefb06 (merge with
> /dev/null as base, instead of punting O==empty case, 2005-11-07).
> This was later further refined to use a better made-up common file
> with fd66dbf5297a (merge-one-file: use empty- or common-base
> condintionally in two-stage merge., 2005-11-10), but the spirit has
> been the same.
>
> But the original fix in f7d24bbefb06 to avoid punging on "both sides

s/punging/punting/

> added" case had a code to unconditionally error out the merge.  When
> this triggers, even though the content-level merge can be done
> cleanly, we end up not saying "content conflict" in the message, but
> still issue the error message, showing "ERROR:  in <pathname>".
>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
--
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]