summaryrefslogtreecommitdiff
path: root/t/t6035-merge-dir-to-symlink.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-07-09merge-recursive: Fix D/F conflictsLibravatar Elijah Newren1-3/+3
The D/F conflicts that can be automatically resolved (file or directory unmodified on one side of history), have the nice property that process_entry() can correctly handle all subpaths of the D/F conflict. In the case of D->F conversions, it will correctly delete all non-conflicting files below the relevant directory and the directory itself (note that both untracked and conflicting files below the directory will prevent its removal). So if we handle D/F conflicts after all other conflicts, they become fairly simple to handle -- we just need to check for whether or not a path (file/directory) is in the way of creating the new content. We do this by having process_entry() defer handling such entries to a subsequent process_df_entry() step. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-09Add additional testcases for D/F conflictsLibravatar Elijah Newren1-4/+60
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28tests: update tests that used to failLibravatar Junio C Hamano1-1/+1
"diff --cc" output t4038 tests was fixed by b810cbb (diff --cc: a lost line at the beginning of the file is shown incorrectly, 2009-07-22), which was actually the commit that introduced this test.. An error in "git merge -s resolve" t6035 tests was fixed by 730f728 (unpack-trees.c: look ahead in the index, 2009-09-20). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-03Aggressive three-way merge: fix D/F caseLibravatar Junio C Hamano1-1/+1
When the ancestor used to have a blob "P", your tree removed it, and the tree you are merging with also removed it, the agressive three-way cleanly merges to remove that blob. If the other tree added a new blob "P/Q" while removing "P", it should also merge cleanly to remove "P" and create "P/Q" (since neither the ancestor nor your tree could have had it, so it is a typical "created in one"). The "aggressive" rule is not new anymore. Reword the stale comment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-03traverse_trees(): handle D/F conflict case sanelyLibravatar Junio C Hamano1-1/+1
traverse_trees() is supposed to call its callback with all the matching entries from the given trees. The current algorithm keeps a pointer to each of the tree being traversed, and feeds the entry with the earliest name to the callback. This breaks down if the trees being traversed looks like this: A B t-1 t t-2 u t/a v When we are currently looking at an entry "t-1" in tree A, and tree B has returned "t", feeding "t" from the B and not feeding anything from A, only because "t-1" sorts later than "t", will miss an entry for a subtree "t" behind the current entry in tree A. This introduces extended_entry_extract() helper function that gives what name is expected from the tree, and implements a mechanism to look-ahead in the tree object using it, to make sure such a case is handled sanely. Traversal in tree A in the above example will first return "t" to match that of B, and then the next request for an entry to A then returns "t-1". This roughly corresponds to what Linus's "prepare for one-entry lookahead" wanted to do, but because this does implement look ahead, t6035 and one more test in t1012 reveal that the approach would not work without adjusting the side that walks the index in unpack_trees() as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09t6035-merge-dir-to-symlink depends on SYMLINKS prerequisiteLibravatar Johannes Sixt1-0/+6
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29git-checkout: be careful about untracked symlinksLibravatar Linus Torvalds1-1/+1
This fixes the case where an untracked symlink that points at a directory with tracked paths confuses the checkout logic, demostrated in t6035. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29lstat_cache: guard against full match of length of 'name' parameterLibravatar Kjetil Barvik1-1/+1
longest_path_match() in symlinks.c does exactly what it's name says, but in some cases that match can be too long, since the has_*_leading_path() functions assumes that the match will newer be as long as the name string given to the function. fix this by adding an extra if test which checks if the match length is equal to the 'len' parameter. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29Demonstrate bugs when a directory is replaced with a symlinkLibravatar Pickens, James E1-0/+87
This test creates two directories, a/b and a/b-2, then replaces a/b with a symlink to a/b-2, then merges that change into the 'baseline' commit, which contains an unrelated change. There are two bugs: 1. 'git checkout' incorrectly deletes work tree file a/b-2/d. 2. 'git merge' incorrectly deletes work tree file a/b-2/d. The test goes on to create another branch in which a/b-2 is replaced with a symlink to a/b (i.e., the reverse of what was done the first time), and merge it into the 'baseline' commit. There is a different bug: 3. The merge should be clean, but git reports a conflict. Signed-off-by: James Pickens <james.e.pickens@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>