Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)

From: Junio C Hamano <junkio@cox.net>
Date: Aug 26, 2005, 22:50 UTC
Message-ID: <7v64tsb9en.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050826213900.GA18880@c165.ib.student.liu.se>

Fredrik Kuivinen <freku045@student.liu.se> writes:

> I find the Git architecture with respect to merging to be quite
> nice. A core which handles the simple cases _fast_ and let the more
> complicated cases be handled by someone else.

Exactly my feeling. The three-way read-tree was made to do "trivial" merges because the three-way merge operation is so fundamental and more importantly because in what it does there is no other plausible heuristics. The cases that it leaves stages unmerged in the index file are cases that a merge policy might want to use heuristics to affect the outcome, and are left for merge-cache to resolve. And it is a good thing.

If the updated read-tree reads more than three trees at once and makes decision internally which ones to choose, it would be very desirable to see an implementation in which there is _no_ heuristics involved in the selection made by the built-in logic.

If there can be better selection made by more expensive logic, and faster but less reliable heuristics by cheaper logic, it would be very nice for the selection logic to call out a helper "merge policy" program or dll module, just like the way merge-cache calls merge-one-file-script, to make that decision.