author | Junio C Hamano <gitster@pobox.com> | |
Fri, 25 Dec 2009 21:40:02 +0000 (13:40 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Sat, 26 Dec 2009 01:10:10 +0000 (17:10 -0800) | ||
commit | 8aa38563b22c84b06ea1fff9638cc1f44fda726f | |
tree | 3631ade1815f7d590ba6e4af48559ed2aab5e382 | tree | snapshot |
parent | 4421a8235783d0664faa9a1d45be114fd7ad8206 | commit | diff |
resolve-undo: teach "update-index --unresolve" to use resolve-undo info
The update-index plumbing command had a hacky --unresolve implementation
that was written back in the days when merge was the only way for users to
end up with higher stages in the index, and assumed that stage #2 must
have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute
the stage #1 information.
There were several issues with this approach:
- These days, merge is not the only command, and conflicts coming from
commands like cherry-pick, "am -3", etc. cannot be recreated by looking
at MERGE_HEAD;
- For a conflict that came from a merge that had renames, picking up the
same path from MERGE_HEAD and HEAD wouldn't help recreating it, either;
- It may have been Ok not to recreate stage #1 back when it was written,
because "diff --ours/--theirs" were the only availble ways to review
conflicts and they don't need stage #1 information. "diff --cc" that
was invented much later is a lot more useful way but it needs stage #1.
We can use resolve-undo information recorded in the index extension to
solve all of these issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The update-index plumbing command had a hacky --unresolve implementation
that was written back in the days when merge was the only way for users to
end up with higher stages in the index, and assumed that stage #2 must
have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute
the stage #1 information.
There were several issues with this approach:
- These days, merge is not the only command, and conflicts coming from
commands like cherry-pick, "am -3", etc. cannot be recreated by looking
at MERGE_HEAD;
- For a conflict that came from a merge that had renames, picking up the
same path from MERGE_HEAD and HEAD wouldn't help recreating it, either;
- It may have been Ok not to recreate stage #1 back when it was written,
because "diff --ours/--theirs" were the only availble ways to review
conflicts and they don't need stage #1 information. "diff --cc" that
was invented much later is a lot more useful way but it needs stage #1.
We can use resolve-undo information recorded in the index extension to
solve all of these issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-update-index.c | diff | blob | history | |
cache.h | diff | blob | history | |
t/t2030-unresolve-info.sh | diff | blob | history |