summaryrefslogtreecommitdiff
path: root/t/t2030-unresolve-info.sh
AgeCommit message (Collapse)Author
2010-01-21Make 'rerere forget' work from a subdirectory.Johannes Sixt
It forgot to apply the prefix to the paths given on the command line. [jc: added test] Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-11rerere forget path: forget recorded resolutionJunio C Hamano
After you find out an earlier resolution you told rerere to use was a mismerge, there is no easy way to clear it. A new subcommand "forget" can be used to tell git to forget a recorded resolution, so that you can redo the merge from scratch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26resolve-undo: teach "update-index --unresolve" to use resolve-undo infoJunio C Hamano
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>
2009-12-26resolve-undo: "checkout -m path" uses resolve-undo informationJunio C Hamano
Once you resolved conflicts by "git add path", you cannot recreate the conflicted state with "git checkout -m path", because you lost information from higher stages in the index when you resolved them. Since we record the necessary information in the resolve-undo index extension these days, we can reproduce the unmerged state in the index and check it out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26resolve-undo: allow plumbing to clear the informationJunio C Hamano
At the Porcelain level, operations such as merge that populate an initially cleanly merged index with conflicted entries clear the resolve-undo information upfront. Give scripted Porcelains a way to do the same, by implementing "update-index --clear-resolve-info". With this, a scripted Porcelain may "update-index --clear-resolve-info" first and repeatedly run "update-index --cacheinfo" to stuff unmerged entries to the index, to be resolved by the user with "git add" and stuff. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26resolve-undo: basic testsJunio C Hamano
Make sure that resolving a failed merge with git add records the conflicted state, committing the result keeps that state, and checking out another commit clears the state. "git ls-files" learns a new option --resolve-undo to show the recorded information. Signed-off-by: Junio C Hamano <gitster@pobox.com>