[Git] recursive merge on 'master' severely broken?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 11, 2018, 07:19 UTC
- Message-ID
- <xmqqmuya43cs.fsf@gitster-ct.c.googlers.com>
It appears that a topic recently graduated to 'master' introduces a severe regression to "git merge" when it merges a side branch that renames paths while the trunk has further updates.
The symptom can easily be seen by trying to recreate the merge I made at the tip of 'pu' 29dea678 ("Merge branch 'sb/filenames-with-dashes' into pu", 2018-04-11) that I'll be. pushing out shortly. The side branch renames a file exec_cmd.h to exec-cmd.h (an underscore changed to a dash) without changing any contents, while the branch being merged to has made some changes to the contents while keeping the original pathname.
A clean automerged result should leave the identical contents from HEAD:exec_cmd.h in :exec-cmd.h in the index, which is what happens when using Git v2.17.0 proper, but with today's master', there are content changes that cannot be explained--the merge is simply broken and worse yet, the command pretends that everything went well and merged cleanly in that path. Overly clever tool that behaves in a buggy and unexplainable way is bad enough, doing so silently is unexcusable.
I suspect that the culprit is the merge e4bb62fa ("Merge branch 'en/rename-directory-detection'", 2018-04-10), and I am planning to revert it out of 'master' as soon as possible, but it is already buried deep in other topics, so I may not be able to get to it until later this week. Sorry about that.