Which is wrong? diff or apply?

Today, I tried this in my git.git checkout:

  $ mv transport-helper.c wt-status.c
  $ git diff -B -M | git apply --cached
  error: wt-status.c: already exists in index

That is, I overwrote the tracked wt-status.c with a completly different file that is also tracked. Then I try to stage the change using git apply.

git diff -B -M reports this:

  diff --git a/transport-helper.c b/wt-status.c
  similarity index 100%
  rename from transport-helper.c
  rename to wt-status.c

Notice that there is no mention that the previously existing wt-status.c was removed. I wonder whether this is a bug.

Or is it the safety valve in git apply that does not allow to overwrite an existing file which should not trigger in this case?

-- Hannes

Johannes Sixt <j6t@kdbg.org> writes:

Honestly speaking, I would consider this a corner case "git apply" bug that nobody cared about so far ;-)

We can read from the above patch that:

 (1) it does not want transport-helper.c in the resulting tree; and

 (2) it does want wt-status.c in the resulting tree the same as
     transport-helper.c from the original tree.

So I do not think a separate "deletion" record is necessary in the diff output. So far, we have tried (and succeeded, I think) hard to avoid creating diffs that talk about the same path twice in a redundant way.

What should "git apply" do in this case then?

The path involved are transport-helper.c (will be removed) and wt-status.c (will be rewritten). The usual "safety" rules should apply to both of them when "apply --index" is run. Namely

 - transport-helper.c, as it will be removed, should not have difference
   from the version in the index; and

 - wt-status.c, as it will be modified to match transport-helper.c, should
   not have difference from the version in the index, either.

If we check the "renamed-to" case differently from the "created-at" case (which I do not think the code does right now), we should be fine, I think.