From: Stephen Bash <bash@genarts.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver
Date: Sun, 9 Sep 2012 10:30:18 -0400 (EDT) [thread overview]
Message-ID: <545618054.286621.1347201018375.JavaMail.root@genarts.com> (raw)
In-Reply-To: <1347165639-12149-1-git-send-email-gitster@pobox.com>
----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Sunday, September 9, 2012 12:40:37 AM
> Subject: [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver
>
> The part that grants Stephen's wish is unchanged from the earlier
> "perhaps like this" patch, but this time with a bit of documentation
> and test.
>
> A more important change between the two actually is [PATCH 2/2].
> When a "binary" synthetic attribute is given to a path, we used to
> (1) disable textual diff and (2) disable CR/LF conversion, but it is
> also sane to disable the textual merge for a path marked as
> "binary", and setting the "-merge" attribute to summon the "binary"
> ll-merge driver is the way to do so.
>
> Junio C Hamano (2):
> merge: teach -Xours/-Xtheirs to binary ll-merge driver
> attr: "binary" attribute should choose built-in "binary" merge
> driver
>
> Documentation/gitattributes.txt | 2 +-
> Documentation/merge-strategies.txt | 3 ++-
> attr.c | 2 +-
> ll-merge.c | 25 ++++++++++++++++++++-----
> t/t6037-merge-ours-theirs.sh | 14 +++++++++++++-
> 5 files changed, 37 insertions(+), 9 deletions(-)
Thanks for this Junio. After figuring out how to make the corporate email server NOT munge the patches, I was able to apply these with no problem. Then
$ git merge -Xtheirs maint
mostly does what I want, but conflicting files deleted on the incoming branch are still marked unmerged/"deleted by them" (binary or not). I'm not sure what the best (most common?) resolution is for that. In my case I would be happy for the -Xtheirs to also delete the files, but that might not always be the right answer (but then again -Xtheirs is a pretty heavy hammer to begin with).
Thanks,
Stephen
prev parent reply other threads:[~2012-09-09 14:30 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
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 ` Stephen Bash [this message]
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=545618054.286621.1347201018375.JavaMail.root@genarts.com \
--to=bash@genarts.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.