Ramkumar Ramachandra <[email protected]> writes:
>
So after a long IRC discussion trying to hash out what you *want* it to
do, here's the summary for everyone else. This test is wrong on several
counts. For simplicity I'll denote by M the subtree merge, called
$new_h in the actual test.
> +test_expect_failure 'log pathspec in tree read into prefix' '
> + git checkout --orphan subtree &&
> + git rm -rf . &&
> + echo foodle >ichi &&
'ichi' also exists in M^1 because you reused a name from another test.
So rename detection will never pair the eventual 'bar/ichi' with this
'ichi', because the 'ichi' path was *modified*, not deleted, w.r.t. M^1.
Just to clarify, rename detection is based on seeing
A foo
D bar
and changing that to
R bar -> foo
assuming the blobs were reasonably similar. And indeed, *copy*
detection (-C) is able to figure it out, because it considers all paths
that were modified as possible candidates for a copy source.
But --follow only uses rename detection.
> + git add ichi &&
> + test_tick &&
> + git commit -m foom &&
> + echo moodle >unrelated &&
> + git add unrelated &&
> + test_tick &&
> + git commit -m quux &&
> + subtree_h=$(git rev-parse HEAD) &&
> + git checkout master &&
> + orig_h=$(git rev-parse HEAD) &&
> + git read-tree --prefix=bar $subtree_h &&
You need to supply a trailing / for the prefix, it's not implied.
> + new_t=$(git write-tree) &&
> + new_h=$(echo "new subtree" |
> + git commit-tree $new_t -p $orig_h -p $subtree_h) &&
> + git reset --hard $new_h &&
> + (
> + cd bar &&
> + git log --oneline ichi >../actual
You need to use --follow, as otherwise the pathspec filtering is
considered fixed.
Note that as discussed in the rest of the thread, --follow is fairly
limited and doesn't *really* solve the problem. But it does work
assuming the filenames are different and you only have one subtree
merge, like in this case.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
