Re: [PATCH v3] mergetool: add automerge configuration

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Right, althought the user can't configure otherwise, and the default 7,
> > it can't hurt to add it.
> 
> Yes, that would make it certain that the code would survive the
> change in the underlying xmerge part of the system.

Yes.

> I am still not sure what the right plan to deal with conflicts
> recorded in the virtual ancestor.  Do we just close our eyes and
> ignore it?

This is what we already do.

When a file has changes that don't bump into each other they are not
considered conflicts, for example:

 BASE:   sentence
 LOCAL:  sentence
 REMOTE: sentence.

Is that a conflict?

Whether you call these "trivial conflicts", or "non-conflicts" doesn't
matter, if the file only has changes of this kind, git considers the
file merged automatically.

If the merge has *all* changes of this kind, then the it is
automatically completed. No mergetool necessary.

> An easy way out may be to give an command line override so that
> users can easily re-run mergetool with the feature disabled only for
> a single invocation that went wrong,

Why would it go wrong?

Git has already determined there's no conflict.

Does it make sense to run "git mergetool
--consider-all-changes-as-conflicts" and go back in time before the
commit merge that had no conflicts was done, and run mergetool on all
the files that contain changes, even if git initially considered the
file as merged (since they contained no "true" conflicts)?

When does it make sense to open an instance of the mergetool on a file
that contains *zero* conflict markers?

-- 
Felipe Contreras