summaryrefslogtreecommitdiff
path: root/t/t2030-unresolve-info.sh
Commit message (Collapse)AuthorAgeFilesLines
* rerere forget: do not segfault if not all stages are presentJohannes Sixt2013-04-041-0/+13
| | | | | | | | | | | | | | | | | | | | The loop that fills in the buffers that are later passed to the merge driver exits early when not all stages of a path are present in the index. But since the buffer pointers are not initialized in advance, the subsequent accesses are undefined. Initialize buffer pointers in advance to avoid undefined behavior later. That is not sufficient, though, to get correct operation of handle_cache(). The function replays a conflicted merge to extract the part inside the conflict markers. As written, the loop exits early when a stage is missing. Consequently, the buffers for later stages that would be present in the index are not filled in and the merge is replayed with incomplete data. Fix it by investigating all stages of the given path. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rerere forget: grok files containing NULJohannes Sixt2013-04-021-0/+12
| | | | | | | | | | Using 'git rerere forget .' after a merge that involved binary files runs into an infinite loop if the binary file contains a zero byte. Replace a strchrnul by memchr because the former does not make progress as soon as the NUL is encountered. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tests: modernise style: more uses of test_line_countStefano Lattarini2012-04-111-1/+1
| | | | | | | | | | | | | | | Prefer: test_line_count <OP> COUNT FILE over: test $(wc -l <FILE) <OP> COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make 'rerere forget' work from a subdirectory.Johannes Sixt2010-01-211-22/+49
| | | | | | | | | 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>
* rerere forget path: forget recorded resolutionJunio C Hamano2010-01-101-0/+25
| | | | | | | | | 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>
* resolve-undo: teach "update-index --unresolve" to use resolve-undo infoJunio C Hamano2009-12-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* resolve-undo: "checkout -m path" uses resolve-undo informationJunio C Hamano2009-12-251-0/+11
| | | | | | | | | | | | 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>
* resolve-undo: allow plumbing to clear the informationJunio C Hamano2009-12-251-0/+12
| | | | | | | | | | | | | | 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>
* resolve-undo: basic testsJunio C Hamano2009-12-251-0/+88
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>