[BUG] merge into unborn branch resets index+WT even if populated

Hi,

I'm posting this on behalf of Dscho who reported it on IRC, but apparently doesn't have the time for email.

If you run the following sequence of commands:

  git init
  echo foo > somefile
  git add somefile
  git pull elsewhere master

(where 'elsewhere' is any repo having a master branch) the "merge into unborn branch" logic silently nukes the index AND worktree copy of "somefile", thereby losing it. The same works with fetch+merge, so it's not pull's fault.

Running git-merge on an unborn branch is supposed to do an index-level merge with the other side, and then update the branch name there. In the common case where the index was empty at the start, this makes 'git pull otherrepo branch' a convenient way to populate the history after 'git init'.

However, if the index was *not* empty, git-merge silently discards *both index and worktree* copies of all files that were tracked, leading to data loss. Exhibit this bug.

Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Here's a less lazy approach at a bug report.

I'm not too happy that noone went for a fix though; this is a real data loss scenario and from his complaints on IRC, Dscho actually hit it and had to reconstruct from the blobs.

 t/t7607-merge-overwrite.sh |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)