Subject: Re: [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver

From: Stephen Bash <[email-masked]>
Date: Sun, 9 Sep 2012 10:30:18 -0400 (EDT)

----- Original Message -----
> From: "Junio C Hamano" <[email-masked]>
> 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