Re: [PATCH, stage1] Better error recovery for merge-conflict markers

[David Malcolm <dmalcolm@redhat.com>]

On Mon, 2016-02-08 at 10:07 +0100, Bert Wesarg wrote:
> David,
> 
> On Thu, Apr 9, 2015 at 10:29 AM, Bert Wesarg <
> bert.wesarg@googlemail.com> wrote:
> > Hi David,
> > 
> > > Various tools that operate on source code files will inject
> > > markers
> > > into them when an unfixable conflict occurs in a merger.
> > > 
> > > There appears to be no blessed standard for these conflict
> > > markers,
> > > but an ad-hoc convention is for 7 '<' , '=', or '>' characters at
> > > the start of a line, followed optionally by a space and optional
> > > text
> > > 
> > > e.g.:
> > > <<<<<<< HEAD
> > > extern int some_var;
> > > =======
> > > extern short some_var;
> > > > > > > > > > Some other branch
> > > 
> > > This convention is followed by GNU patch:
> > >   http://git.savannah.gnu.org/cgit/patch.git/tree/src/merge.c
> > > by git:
> > > 
> > > http://git.kernel.org/cgit/git/git.git/tree/Documentation/merge-c
> > > onfig.txt
> > > and by various other tools.
> > 
> > 
> > if you read both of these tools carefully, you will notice an
> > alternative
> > conflict style (named 'diff3' in both of them), that includes a
> > third
> > section, the common pre-image. Here is an example:
> > 
> > <<<<<<< HEAD
> > extern int some_var;
> > > > > > > > > merge base
> > extern int var;
> > =======
> > extern short var;
> > > > > > > > > 
> > > > > > > > > Some other branch
> > 
> > 
> > Additionally, git supports a custom conflict-marker-size to change
> > the
> > default of 7 on a per file name (the conflict-marker-size
> > attribute). So it
> > may be worthwhile to support other sizes than 7 in this patch too.
> 
> you never commentewd on my mail, but I saw this now in trunk. I can
> only repeat myself here.

Thanks.  FWIW I did read your mail, and it was a factor in me proposing
this alternate implementation which would be more flexible:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01515.html
but that implementation had the drawback of not working with .i files
from -save-temps, so we went with the original approach.