Junio C Hamano wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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
