Re: [RFC] Merge strategy 'applyreject'

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 13, 2006, 21:38 UTC
Message-ID: <20060913213820.GC30782@spearce.org>
In-Reply-To: <ee9spf$h98$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> wrote:

Show 8 quoted lines

> > ---
> >  .gitignore               |    1 +
> >  Makefile                 |    1 +
> >  git-merge-applyreject.sh |   26 ++++++++++++++++++++++++++
> >  git-merge.sh             |    2 +-
> >  4 files changed, 29 insertions(+), 1 deletions(-)
> 
> But where documentation (Documentation/merge-strategies.txt)?

If its interesting I'll document it.  I just threw it together and
tossed it out there to see what others thought of the general idea.

Show 8 quoted lines

> > +#!/bin/sh
> > +#
> > +# Simple merge strategy which produces reject files on failed merges.
> > +# Only handles two heads and one merge base, thus the command line
> > +# parameters must be:  base -- head1 head2
> 
> We can always get the base using git-merge-base, so the arguments could
> be either "base -- head1 head2", or just "head1 head2".

Actually the merge driver (git-merge.sh) feeds us the arguments like
that.

> Does "git pull -s applyreject . head2" works (when on head1) with
> this patch? Does the unified driver git-merge works correctly?

Yes.  That's how I tested it.

> > +git-diff --binary -M $base $incoming \
> > +     | git-apply --index --reject --verbose
> 
> --index or --cached?

I believe that --index is correct. I want to patch the file in the working directory, not the one that's currently in the index. I also want to update the index if the patch applied cleanly.

-- 
Shawn.