merge-one-file: remove stale comment

The "funny filename" comment was from b539c5e8fbd3 (git-merge-one:
new merge world order., 2005-12-07) where the removed code just
before that new comment ended with:

        merge "$4" "$orig" "$src2"

(yes, we used to use "merge" program from the RCS suite).  The
comment refers to one of the bad side effect the old code used to
have and warns against such a practice, i.e. it was talking about
the code that no longer existed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge-one-file: style cleanup

Update style to match Documentation/CodingGuidelines.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge-one-file: send "ERROR:" messages to stderr

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-one-file: force content conflict for "both sides added" case

Historically, we tried to be lenient to "both sides added, slightly
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 punting on "both sides
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>".

Move that "always fail for add/add conflict" logic a bit higher to
fix this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>