Junio C Hamano <[email protected]> writes:
> Linus Torvalds <[email protected]> writes:
>
>> Now, the reason it was marked as changed is that the xfs branch _had_
>> in fact changed it, but the changes were already upstream and got
>> merged away. But the file still got written out (with the same
>> contents it had before the merge), and 'make' obviously only looks at
>> modification time, so make rebuilt everything.
>
> Thanks for a clear description of the issue. It does sound
> interesting.
A bit of detour. "Change in side branch happened to be a subset of
the change in trunk and gets subsumed, but we end up writing the
same result" happens also with the simpler resolve strategy.
Here is a fix.
git-merge-one-file.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 9879c59395..aa7392f7ff 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -137,11 +137,21 @@ case "${1:-.}${2:-.}${3:-.}" in
ret=1
fi
+ # Does the merge result happen to be identical to what we
+ # already have? Then do not cause unnecessary recompilation.
+ # But don't bother the optimization if we need to chmod
+ if cmp -s "$4" "$src1" && test "$6" = "$7"
+ then
+ :; # happy
+ else
+
# Create the working tree file, using "our tree" version from the
# index, and then store the result of the merge.
git checkout-index -f --stage=2 -- "$4" && cat "$src1" >"$4" || exit 1
rm -f -- "$orig" "$src1" "$src2"
+ fi
+
if test "$6" != "$7"
then
if test -n "$msg"
