Re: [PATCH] t4202 (log): add failing test for log with subtree

[Thomas Rast <trast@inf.ethz.ch>]

Ramkumar Ramachandra <artagnon@gmail.com> 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