When merging two files which contain newlines at the end, the blob
created (with conflicts) is the
same as two files created without newlines at the end.
We can demonstrate the same using this simple script which uses
`git-merge-tree(1)`. The script
creates two files in master, newBranch and then merges the tree. The
created files seem to have
the same content, eventhough the source files differed by newlines.
#!/usr/bin/env bash
git init
git commit --allow-empty -m "base commit"
git branch newBranch
echo -ne "\nA\n" > newline
echo -ne "\nA" > half
git add .
git commit -m "master commit"
git checkout newBranch
echo -ne "\nB\n" > newline
echo -ne "\nB" > half
git add .
git commit -m "branch commit"
treeOID=$(git merge-tree master newBranch | head -n1)
halfOID=$(git cat-file -p $treeOID | grep half | awk '{print $3}')
newlineOID=$(git cat-file -p $treeOID | grep newline | awk '{print $3}')
if [[ $halfOID == $newlineOID ]]; then
exit 1
else
exit 0
fi
Is this expected behavior? Shouldn't the two merged files (newline,
half) differ? i.e., shouldn't the file (newline) with newlines at the
end
contain an extra newline compared to the file without the newline? (half).
If this is expected behavior, what would be the best way to
differentiate the two? This is not a bug introduced, but rather the
behavior since,
the start, which makes me think that I'm missing something (verified
via git bisect on latest git).
The context of this is that it is hard to programmatically resolve
conflicts without loosing information, since we don't know if there
should
be a newline suffix in the file or not.
