Elijah Newren <newren@xxxxxxxxx> writes: > Each individual file involved in a rename could have also been modified > on both sides of history, meaning it may need to have content merges. > If two such files are renamed into the same location, then on top of the > two natural auto-merging messages we also have to two-way merge the > result, giving us messages that look like > > Auto-merging somefile.c (was somecase.c) > Auto-merging somefile.c (was somefolder.c) > Auto-merging somefile.c > > However, despite the fact that I was the one who put the "(was %s)" > portions into the messages (and just a few months ago), I was still > initially confused when running into a rename/rename(2to1) case and > wondered if somefile.c had been merged three times. Update this to > instead be: > > Auto-merging version of somefile.c from somecase.c > Auto-merging version of somefile.c from someportfolio.c > Auto-merging somefile.c > > This is an admittedly long set of messages for a single path, but you > only get all three messages when dealing with the rare case of a > rename/rename(2to1) conflict where both sides of both original files > were also modified, in conflicting ways. Yeah, that does look mouthful, but definitely is more understandable.
