Johannes Sixt <j6t@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html