Re: Optimizing writes to unchanged files during merges?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2018, 01:44 UTC
Message-ID: <xmqqbmekylgc.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CA+55aFwi9pTAJT_qtv=vHLgu=B1fdXBoD96i8Y5xnbS=zrfSzg@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 9 quoted lines

> How about we take a completely different approach? Instead of relying
> on fragile (but clever) tests, why not rely on stupid brute force?
>
> Yeah, yeah, it's bad to be stupid, but sometimes simple and stupid
> really does work.
>
> See the attached patch. It gets rid of all the subtle "has this been
> renamed" tests entirely, and just _always_ does that final
> update_file().

I think Elijah's corrected was_tracked() also does not care "has this been renamed".

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.

Your illustration patch that reads from the working tree to compare with the contents we are about to write out of course won't cope with this case ;-). If we do things in the index like the approach to fix was_tracked(), I suspect that we would just say "as long as the index and the HEAD matches, i.e. we are keeping the pathas it is found in HEAD as the merge result, we do not touch the working tree" and leave such a local modification alone.