On Thu, Apr 12, 2018 at 2:46 PM, Junio C Hamano <gits...@pobox.com> wrote:
>
> Thanks for a clear description of the issue. It does sound
> interesting.
I decided to show it with a simpler case that could be scripted and
doesn't need the kernel.
NOTE! This obviously doesn't happen for files with the trivial merge
cases (ie the ones that don't require any real merging at all).
There *is* a three-way merge going on, it's just that the end result
is the same as the original file.
Example script just appended here at the end.
NOTE: The script uses "ls -l --full-time", which afaik is a GNU ls
extension. So the script below is not portable.
Linus
---
# Create throw-away test repository
mkdir merge-test
cd merge-test
git init
# Create silly baseline file with 10 lines of numbers in it
for i in $(seq 1 10); do echo $i; done > a
git add a
git commit -m"Original"
# Make a branch that changes '9' to 'nine'
git checkout -b branch
sed -i 's/9/nine/' a
git commit -m "Nine" a
# On the master, change '2' to 'two' _and_ '9' to 'nine'
git checkout master
sed -i 's/9/nine/' a
sed -i 's/2/two/' a
git commit -m "Two and nine" a
# sleep to show the time difference
sleep 1
# show the date on 'a' and do the merge
ls -l --full-time a
git merge -m "Merge contents" branch
# The merge didn't change the contents, but did rewrite the file
ls -l --full-time a
