Commit graph

7 commits

Author SHA1 Message Date
Junio C Hamano df3dac3758 tests: update tests that used to fail
"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-28 00:41:52 -08:00
Junio C Hamano cee2d6ae63 Aggressive three-way merge: fix D/F case
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-03 23:25:13 -08:00
Junio C Hamano 1ee26571e9 traverse_trees(): handle D/F conflict case sanely
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>
2010-01-03 23:21:32 -08:00
Johannes Sixt b6b0737d02 t6035-merge-dir-to-symlink depends on SYMLINKS prerequisite
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 10:37:24 -07:00
Linus Torvalds b6986d8a75 git-checkout: be careful about untracked symlinks
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-29 20:24:28 -07:00
Kjetil Barvik 77716755cb lstat_cache: guard against full match of length of 'name' parameter
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-29 20:20:12 -07:00
Pickens, James E 4f6339b0c3 Demonstrate bugs when a directory is replaced with a symlink
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>
2009-07-29 20:18:25 -07:00