Re: Expected Behavior?

From: Junio C Hamano <junkio@cox.net>
Date: Nov 9, 2005, 23:36 UTC
Message-ID: <7virv18kc3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> writes:

Show 6 quoted lines

> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
>> The world would be so much better if there would be just a _single_
>> per-file automerger instead of three right now...
>
> I don't quite agree with this. The multi-merger mechanism is something
> (relatively) unique and powerful in GIT.

If I am reading you two correctly, you are not disagreeing, but are talking about different issues.

Pasky is talking about what to do after merge strategy finds that a path (from three stages) needs to be merged. git-core uses git-merge-one-file or git-merge-recursive::mergeFile (which are the implementations of the same logic), and Pasky has his own in Cogito.

Fredrik's using his own mergeFile is defensible from both performance and implementation point of view. After the rename processing stage, he already extracted enough information from trees involved, and there is no reason for him to be preparing three stages in the index file with that information (which is cumbersome because there is no interface to populate the higher stage directly using git-update-index --- you have to first create temporary tree objects and ask git-read-tree -m to do so) and asking git-merge-index to call git-merge-one-file. If you read git-merge-one-file, it is not a rocket science. While we _may_ want to keep the logic that decides what to do in various cases across these three implementations, at least for me, it does not particularly feel disturbing, especially when there are good reasons.