git/t/t8009-blame-vs-topicbranches.sh

39 lines
890 B
Bash
Raw Permalink Normal View History

blame: test to describe use of blame --reverse --first-parent Reverse blame can be used to locate removal of lines which does not change adjacent lines. Such edits do not appear in non-reverse blame, because the adjacent lines last changed commit is older history, before the edit. For a big and active project which uses topic branches, or analogous feature, for example pull-requests, the history can contain many concurrent branches, and even after an edit merged into the target branch, there are still many (sometimes several tens or even hundreds) topic branch which do not contain it: a0--a1-----*a2-*a3-a4...-*a100 |\ / / / | b0-B1..bN / / |\ / / | c0.. ..cN / \ / z0.. ..zN Here, the '*'s mark the first parent in merge, and uppercase B1 - the commit where the line being blamed for was removed. Since commits cN-zN do not contain B1, they still have the line removed in B1, and reverse blame can report that the last commit for the line was zN (meaning that it was removed in a100). In fact it really does return some very late commit, and this makes it unusable for finding the B1 commit. The search could be done by blame --reverse --first-parent. For range a0..a100 it would return a1, and then only one additional blame along the a0..bN will return the desired commit b0. But combining --reverse and --first-parent was forbidden in 95a4fb0eac, because incorrectly specified range could produce unexpected and meaningless result. Add test which describes the expected behavior of `blame --reverse --first-parent` in the case described above. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-30 05:01:51 +00:00
#!/bin/sh
test_description='blaming through history with topic branches'
TEST_PASSES_SANITIZE_LEAK=true
blame: test to describe use of blame --reverse --first-parent Reverse blame can be used to locate removal of lines which does not change adjacent lines. Such edits do not appear in non-reverse blame, because the adjacent lines last changed commit is older history, before the edit. For a big and active project which uses topic branches, or analogous feature, for example pull-requests, the history can contain many concurrent branches, and even after an edit merged into the target branch, there are still many (sometimes several tens or even hundreds) topic branch which do not contain it: a0--a1-----*a2-*a3-a4...-*a100 |\ / / / | b0-B1..bN / / |\ / / | c0.. ..cN / \ / z0.. ..zN Here, the '*'s mark the first parent in merge, and uppercase B1 - the commit where the line being blamed for was removed. Since commits cN-zN do not contain B1, they still have the line removed in B1, and reverse blame can report that the last commit for the line was zN (meaning that it was removed in a100). In fact it really does return some very late commit, and this makes it unusable for finding the B1 commit. The search could be done by blame --reverse --first-parent. For range a0..a100 it would return a1, and then only one additional blame along the a0..bN will return the desired commit b0. But combining --reverse and --first-parent was forbidden in 95a4fb0eac, because incorrectly specified range could produce unexpected and meaningless result. Add test which describes the expected behavior of `blame --reverse --first-parent` in the case described above. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-30 05:01:51 +00:00
. ./test-lib.sh
# Creates the history shown below. '*'s mark the first parent in the merges.
# The only line of file.t is changed in commit B2
#
# +---C1
# / \
# A0--A1--*A2--*A3
# \ /
# B1-B2
#
test_expect_success setup '
test_commit A0 file.t line0 &&
test_commit A1 &&
git reset --hard A0 &&
test_commit B1 &&
test_commit B2 file.t line0changed &&
git reset --hard A1 &&
test_merge A2 B2 &&
git reset --hard A1 &&
test_commit C1 &&
git reset --hard A2 &&
test_merge A3 C1
'
test_expect_success 'blame --reverse --first-parent finds A1' '
blame: test to describe use of blame --reverse --first-parent Reverse blame can be used to locate removal of lines which does not change adjacent lines. Such edits do not appear in non-reverse blame, because the adjacent lines last changed commit is older history, before the edit. For a big and active project which uses topic branches, or analogous feature, for example pull-requests, the history can contain many concurrent branches, and even after an edit merged into the target branch, there are still many (sometimes several tens or even hundreds) topic branch which do not contain it: a0--a1-----*a2-*a3-a4...-*a100 |\ / / / | b0-B1..bN / / |\ / / | c0.. ..cN / \ / z0.. ..zN Here, the '*'s mark the first parent in merge, and uppercase B1 - the commit where the line being blamed for was removed. Since commits cN-zN do not contain B1, they still have the line removed in B1, and reverse blame can report that the last commit for the line was zN (meaning that it was removed in a100). In fact it really does return some very late commit, and this makes it unusable for finding the B1 commit. The search could be done by blame --reverse --first-parent. For range a0..a100 it would return a1, and then only one additional blame along the a0..bN will return the desired commit b0. But combining --reverse and --first-parent was forbidden in 95a4fb0eac, because incorrectly specified range could produce unexpected and meaningless result. Add test which describes the expected behavior of `blame --reverse --first-parent` in the case described above. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-30 05:01:51 +00:00
git blame --porcelain --reverse --first-parent A0..A3 -- file.t >actual_full &&
head -n 1 <actual_full | sed -e "s/ .*//" >actual &&
git rev-parse A1 >expect &&
test_cmp expect actual
'
test_done