Jeff King <p...@peff.net> writes: > On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote: > >> I dug this all the way down to your cb93c19 (merge-one-file: use common >> as base, instead of emptiness., 2005-11-09), which states that the goal >> is just to get: >> >> common file contents... >> <<<<<< FILENAME >> version from our branch... >> ====== >> version from their branch... >> >>>>>> .merge_file_XXXXXX >> more common file contents... >> >> But that seems to be what we produce now. Did all of this simply predate >> xdl_merge, and the crappy rcs merge did not bother minimizing the diff? >> That certainly seems to be the case in my tests. >> >> If that is the case, I think we can get rid of the complex >> create_virtual_base(), as well. > > So here is what I would propose: > > [1/3]: merge-one-file: use empty blob for add/add base > [2/3]: merge-tree: drop generate_common strategy > [3/3]: xdiff: drop XDL_EMIT_COMMON > > I briefly wondered if there were any bugs in merge-one-file around this > "no newline at end of file" issue. But there shouldn't be. It generates > the common file by applying the diff to the first file with "--no-add", > which should do the right thing, I think. > > I stopped short of dropping the create_virtual_base function in the > first patch, for reasons explained there. But if we were to do so, I > suspect we could deprecated and eventually drop "apply --no-add", too.
Thanks. I think the "virtual" stuff started its life outside sh-setup but later was moved there for p4merge. The log message for 4549162e (mergetools/p4merge: create a base if none available, 2013-03-13) seems to indicate that using an empty file does not work well over there as you suspected, so unfortunately we cannot lose it just yet. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
