Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>> Ah, I forgot about that one. I think "the number of conflicts" was
>> a UI mistake (the original that it mimics is "merge" from RCS suite,
>> which uses 1 and 2 for "conflicts" and "trouble") but we know we
>> will get conflicts, so it is wrong to expect success from the
>> command. Deliberately ignoring the return status is the right thing
>> to do.
>
> I agree. My bet is that nobody is checking the return status of "git
> merge-file" to find out the number of conflicts. Plus, how can you check
> the difference between 255 conflicts and error -1?
Yup, I already mentioned UI mistake so you do not have to repeat it
to consume more bandwidth. We're in agreement already.
> We could do something like --marker-size=13 to minimize the chances of
> that happening.
>
> In that case I would prefer '/^<\{13\} /' (to avoid too many
> characters). I see those regexes used elsewhere in git, but I don't know
> how portable that is.
If it is used elsewhere with "sed", then that would be OK, but if it
is not with "sed" but with "grep", that's quite a different story.
> So, do we want those three things?
>
> 1. A non-standard marker-size
> 2. Check beforehand the existence of those markers and disable
> automerge
> 3. Check afterwards the existence of those markers and disable
> automerge
I do not think 3 is needed if we do 2 and I do not think 1 would
particularly be useful *UNLESS* the code consults with the attribute
system to see what marker size the path uses to avoid crashing with
the non-standard marker-size the path already uses.
So the easiest would be not to do anything for now, with a note
about known limitations in the doc. The second easiest would be to
do 2. alone. We could do 1. to be more complete but I tend to think
that it is better to leave it as #leftoverbits.
