Re: Optimizing writes to unchanged files during merges?

[Elijah Newren <newren@gmail.com>]

On Sun, Apr 15, 2018 at 7:03 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sun, Apr 15, 2018 at 6:44 PM, Junio C Hamano <gitster@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.