From: Stephen Bash <bash@genarts.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/2] attr: "binary" attribute should choose built-in "binary" merge driver
Date: Wed, 12 Sep 2012 08:58:01 -0400 (EDT) [thread overview]
Message-ID: <1734879571.321704.1347454681726.JavaMail.root@genarts.com> (raw)
In-Reply-To: <7vk3vzfwme.fsf@alter.siamese.dyndns.org>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Wednesday, September 12, 2012 4:55:53 AM
> Subject: Re: [PATCH 2/2] attr: "binary" attribute should choose built-in "binary" merge driver
>
> Jeff King <peff@peff.net> writes:
>
> > On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
> >
> >> The built-in "binary" attribute macro expands to "-diff -text", so
> >> that textual diff is not produced, and the contents will not go
> >> through any CR/LF conversion ever. During a merge, it should also
> >> choose the "binary" low-level merge driver, but it didn't.
> >>
> >> Make it expand to "-diff -merge -text".
> >
> > Yeah, that seems like the obviously correct thing to do. In
> > practice,
> > most files would end up in the first few lines of ll_xdl_merge
> > checking
> > buffer_is_binary anyway, so I think this would really only make a
> > difference when our "is it binary?" heuristic guesses wrong.
>
> You made me look at that part again and then made me notice
> something unrelated.
>
> if (buffer_is_binary(orig->ptr, orig->size) ||
> buffer_is_binary(src1->ptr, src1->size) ||
> buffer_is_binary(src2->ptr, src2->size)) {
> warning("Cannot merge binary files: %s (%s vs. %s)",
> path, name1, name2);
> return ll_binary_merge(drv_unused, result,
> path,
> orig, orig_name,
> src1, name1,
> src2, name2,
> opts, marker_size);
> }
>
> Given that we now may know how to merge these things, the
> unconditional warning feels very wrong.
>
> Perhaps something like this makes it better.
Patch didn't apply on top of the previous two for me, but after making the edits manually does what it claims to do (and makes the merge output much nicer to read, thanks!). The only remaining question for me is should -Xtheirs resolve "deleted by them" conflicts?
Thanks,
Stephen
next prev parent reply other threads:[~2012-09-12 12:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1799969825.275125.1347028392272.JavaMail.root@genarts.com>
2012-09-07 14:48 ` Binary file-friendly merge -Xours or -Xtheirs? Stephen Bash
2012-09-07 21:47 ` Junio C Hamano
2012-09-09 4:40 ` [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver Junio C Hamano
2012-09-09 4:40 ` [PATCH 1/2] merge: teach " Junio C Hamano
2012-09-09 4:40 ` [PATCH 2/2] attr: "binary" attribute should choose built-in "binary" merge driver Junio C Hamano
2012-09-10 14:03 ` Jeff King
2012-09-12 8:55 ` Junio C Hamano
2012-09-12 12:58 ` Stephen Bash [this message]
2012-09-12 17:01 ` Junio C Hamano
2012-09-12 17:50 ` Stephen Bash
2012-09-12 13:17 ` Jeff King
2012-09-09 14:30 ` [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver Stephen Bash
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1734879571.321704.1347454681726.JavaMail.root@genarts.com \
--to=bash@genarts.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).