Expected Behavior?

[Jon Loeliger <jdl@freescale.com>]

I was working through some examples and found some
rather curious behavior.  I'm wondering if it is
expected or not.  This isn't quite minimal, but
it is still small and shows the weirdness:

    git-init-db
    echo "Stuff for file1" > file1
    echo "Stuff for file2" > file2

    git add file1 file2
    git commit -m "Initial file1 and file2"

    git checkout -b dev

    echo "More for file1" >> file1
    rm -f file2
    echo "Another file!" > file3

    git update-index file1
    git update-index --force-remove file2
    git add file3

    git commit -m "Updated some stuff."

    git checkout master
    echo "Stuff for a conflict." >> file3
    git add file3
    git commit -m "Master update of file3"

    git merge "Grab dev stuff" master dev

Then, the part that I think is odd is demonstrated by "git status":

    $ git status
    #
    # Updated but not checked in:
    #   (will commit)
    #
    #       modified: file1
    #       deleted:  file2
    #       unmerged: file3
    #
    #
    # Changed but not updated:
    #   (use git-update-index to mark for commit)
    #
    #       unmerged: file3
    #
    #
    # Untracked files:
    #   (use "git add" to add to commit)
    #
    #       file3

Why is file3 considered untracked and needing to be added?
It was present in both "dev" and "master" branches before
the merge.  It doesn't end up with "<<< one === other >>>"
style diffs either.

My guess is that the file is small, one line, in each branch.
When the diff happens, it sees the file as empty in the other
branch and considers that "new" directly, rather than asking
the index if it knows about it to determine "newness" status.

Or perhaps it is that the file  became new in each branch
independently and never really had a true common ancestor.

Thanks,
jdl