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

From: Thomas Rast <trast@inf.ethz.ch>
Date: Apr 22, 2013, 13:15 UTC
Message-ID: <87ppxmogdv.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <1366632487-28153-1-git-send-email-artagnon@gmail.com>

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.

Show 11 quoted lines

> +	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.

Show 7 quoted lines

> +	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