Re: Which is wrong? diff or apply?

Johannes Sixt [off-list ref] writes:

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.

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.