kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Elijah Newren	6d63070cac	merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest Earlier in this series, the patch "merge-recursive: add handling for rename/rename/add-dest/add-dest" added code to handle the rename on each side of history also being involved in a rename/add conflict, but only did so in the non-recursive case. Add code for the recursive case, ensuring that the "added" files are not simply deleted. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	b630b81470	t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify This is another testcase trying to exercise the virtual merge base creation in the rename/rename(1to2) code. A testcase is added that we should be able to merge cleanly, but which requires a virtual merge base to be created that correctly handles rename/add-dest conflicts within the rename/rename(1to2) testcase handling. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	434b8525e7	merge-recursive: Consider modifications in rename/rename(2to1) conflicts Our previous conflict resolution for renaming two different files to the same name ignored the fact that each of those files may have modifications from both sides of history to consider. We need to do a three-way merge for each of those files, and then handle the conflict of both sets of merged contents trying to be recorded with the same name. It is important to note that this changes our strategy in the recursive case. After doing a three-way content merge of each of the files involved, we still are faced with the fact that we are trying to put both of the results (including conflict markers) into the same path. We could do another two-way merge, but I think that becomes confusing. Also, taking a hint from the modify/delete and rename/delete cases we handled earlier, a more useful "common ground" would be to keep the three-way content merge but record it with the original filename. The renames can still be detected, we just allow it to be done in the o->call_depth=0 case. This seems to result in simpler & easier to understand merge conflicts as well, as evidenced by some of the changes needed in our testsuite in t6036. (However, it should be noted that this change will cause problems those renames also occur along with a file being added whose name matches the source of the rename. Since git currently cannot detect rename/add-source situations, though, this codepath is not currently used for those cases anyway. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	c52ff85d97	merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base When renaming one file to two files, we really should be doing a content merge. Also, in the recursive case, undoing the renames and recording the merged file in the index with the source of the rename (while deleting both destinations) allows the renames to be re-detected in the non-recursive merge and will result in fewer spurious conflicts. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	ec61d14963	merge-recursive: Fix modify/delete resolution in the recursive case When o->call_depth>0 and we have conflicts, we try to find "middle ground" when creating the virtual merge base. In the case of content conflicts, this can be done by doing a three-way content merge and using the result. In all parts where the three-way content merge is clean, it is the correct middle ground, and in parts where it conflicts there is no middle ground but the conflict markers provide a good compromise since they are unlikely to accidentally match any further changes. In the case of a modify/delete conflict, we cannot do the same thing. Accepting either endpoint as the resolution for the virtual merge base runs the risk that when handling the non-recursive case we will silently accept one person's resolution over another without flagging a conflict. In this case, the closest "middle ground" we have is actually the merge base of the candidate merge bases. (We could alternatively attempt a three way content merge using an empty file in place of the deleted file, but that seems to be more work than necessary.) Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	0a6b87126e	merge-recursive: Make dead code for rename/rename(2to1) conflicts undead The code for rename_rename_2to1 conflicts (two files both being renamed to the same filename) was dead since the rename/add path was always being independently triggered for each of the renames instead. Further, reviving the dead code showed that it was inherently buggy and would always segfault -- among a few other bugs. Move the else-if branch for the rename/rename block before the rename/add block to make sure it is checked first, and fix up the rename/rename(2to1) code segments to make it handle most cases. Work is still needed to handle higher dimensional corner cases such as rename/rename/modify/modify issues. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	ed0148a520	merge-recursive: Allow make_room_for_path() to remove D/F entries If there were several files conflicting below a directory corresponding to a D/F conflict, and the file of that D/F conflict is in the way, we want it to be removed. Since files of D/F conflicts are handled last, they can be reinstated later and possibly with a new unique name. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	7b1c610f84	merge-recursive: Fix recursive case with D/F conflict via add/add conflict When a D/F conflict is introduced via an add/add conflict, when o->call_depth > 0 we need to ensure that the higher stage entry from the base stage is removed. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	0b35deb378	t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify This is another challenging testcase trying to exercise the virtual merge base creation in the rename/rename(1to2) code. A testcase is added that we should be able to merge cleanly, but which requires a virtual merge base to be created that is aware of rename/rename(1to2)/add-source conflicts and can handle those. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	a0d3311624	t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify This test is mostly just designed for testing optimality of the virtual merge base in the event of a rename/rename(1to2) conflict. The current choice for resolving this in git seems somewhat confusing and suboptimal. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	827f2b7d29	t6036: tests for criss-cross merges with various directory/file conflicts Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	96b079e5c9	t6036: criss-cross with weird content can fool git into clean merge Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	fe7e9c23e4	t6036: Add differently resolved modify/delete conflict in criss-cross test Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	695576fddd	t6042: Add a testcase where git deletes an untracked file Current git will nuke an untracked file during a rename/delete conflict if (a) there is an untracked file whose name matches the source of a rename and (b) the merge is done in a certain direction. Add a simple testcase demonstrating this bug. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Jonathan Nieder	a48fcd8369	tests: add missing && Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	2a669c341a	merge-recursive: Avoid doubly merging rename/add conflict contents When a commit moves A to B while another commit created B (or moved C to B), and these two different commits serve as different merge-bases for a later merge, `c94736a` (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added some special code to avoid segfaults. Since that commit, the two versions of B are merged in place (which could be potentially conflicting) and the intermediate result is used as the virtual ancestor. However, right before this special merge, try_merge was turned on, meaning that process_renames() would try an alternative merge that ignores the 'add' part of the conflict, and, if the merge is clean, store that as the new virtual ancestor. This could cause incorrect merging of criss-cross merges; it would typically result in just recording a slightly confusing merge base, but in some cases it could cause silent acceptance of one side of a merge as the final resolution when a conflict should have been flagged. When we do a special merge for such a rename/add conflict between merge-bases, turn try_merge off to avoid an inappropriate second merge. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	f63622c0a9	t6036: Add testcase for undetected conflict If merging two lines of development involves a rename/add conflict, and two different people make such a merge but resolve it differently, and then someone tries to merge the resulting two merges, then they should clearly get a conflict due to the different resolutions from the previous developers. However, in some such cases the conflict would not be detected and git would silently accept one of the two versions being merged as the final merge resolution. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	583942df09	t6036: Add a second testcase similar to the first but with content changes `c94736a` (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added t6036 with a testcase that involved dual renames and a criss-cross merge. Add a test that is nearly identical, but which also involves content modification -- a case git currently does not merge correctly. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Elijah Newren	c976260d0f	t6036: Test index and worktree state, not just that merge fails `c94736a` (merge-recursive: don't segfault while handling rename clashes 2009-07-30) added this testcase with an interesting corner case test, which previously had cased git to segfault. This test ensures that the segfault does not return and that the merge correctly fails; just add some checks that verify the state of the index and worktree after the merge are correct. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	14 years ago
Junio C Hamano	c94736a27f	merge-recursive: don't segfault while handling rename clashes When a branch moves A to B while the other branch created B (or moved C to B), the code tried to rename one of them to B~something to preserve both versions, and failed to register temporary resolution for the original path B at stage#0 during virtual ancestor computation. This left the index in unmerged state and caused a segfault. A better solution is to merge these two versions of B's in place and use the (potentially conflicting) result as the intermediate merge result in the virtual ancestor. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago

21 Commits (d5f6b1d756a29255efedee3cb6e8526aedcfeb00)