[Bug?] Information around newlines lost in merge

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.