[RFH] Merge driver
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:05
Some people may be alarmed and feel concerned that I already have Daniel's and Fredrik's merge in the "master" branch; I feel this deserves some clarification. The change Daniel made is a natural enhancement of an existing program. It spent unusually long time in the proposed update queue exactly because read-tree was so fundamental, and I wanted to make sure there is no serious regression. Most importantly, the original merge mechanism, git-resolve, is not dropped, and 'git-pull' uses that, not 'git-merge', after fetching a remote head. So for everyday use, nothing has changed. I did the 'git-merge' strategy backend mechanism because I wanted to play it safe. It makes it easy to give the set of conservative strategies as default for every day use, while allowing us to try more experimental strategies which can be used only by an explicit user request. Introduction of additional merge strategies, such as the Fredrik merge or rename-detect merge which is yet to be written, is in a sense similar to adding new filesystems to the stable kernel tree -- as long as they stay optional and do not touch the core deeply, they tend to be safer changes than other kinds, and we can add them more or less anytime in the stable series without impacting stability. I intend to eventually update git-pull to use git-merge, and I am hoping that I can do so before we hit 1.0, once we are sure that 'git-merge -s stupid' behaves identically as 'git-resolve', and 'git-merge -s resolve' fares no worse than 'git-resolve'. I personally feel I've done enough tests to ensure that already, but help from the community is as always appreciated.