On Sun, Apr 15, 2018 at 7:03 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> One thing that makes me curious is what happens (and what we want to >> happen) when such a "we already have the changes the side branch >> tries to bring in" path has local (i.e. not yet in the index) >> changes. For a dirty file that trivially merges (e.g. a path we >> modified since our histories forked, while the other side didn't do >> anything, has local changes in the working tree), we try hard to >> make the merge succeed while keeping the local changes, and we >> should be able to do the same in this case, too. > > I think it might be nice, but probably not really worth it. <snip> > So I don't think it's a big deal, and I'd rather have the merge fail > very early with "that file has seen changes in the branch you are > merging" than add any real complexity to the merge logic. That's actually problematic, and not yet possible with the current merge-recursive code. The fail-very-early code is in unpack_trees(), and it doesn't understand renames. By the time we get to the rest of the logic of merge-recursive, unpack_trees() has already written updates to lots of files throughout the tree, so bailing and leaving the tree in a half-merged state is no longer an option. (The logic in merge-recursive.c is excessively complex in part due to this issue, making it implement what amounts to a four-way merge instead of just a three-way merge. It's gross.) So, if we were to use the brute-force scheme here, when renames are involved, we'd need to have some special logic for handling dirty files. That logic would probably include checking the original index for both modification times (to determine if the file is dirty), and for comparison of contents. In short, we'd still need all the logic that this scheme was trying to get rid of in the first place.
