summaryrefslogtreecommitdiff
path: root/t/t5321-pack-large-objects.sh
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2019-07-31 08:18:46 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-07-31 12:24:07 -0700
commit4e6023b13ae1159277a7c3053f8d074c23456812 (patch)
treeac304717a36078d497aec92cb9448d059a971b7f /t/t5321-pack-large-objects.sh
parentt3427: accommodate for the `rebase --merge` backend having been replaced (diff)
downloadtgif-4e6023b13ae1159277a7c3053f8d074c23456812.tar.xz
t3427: fix another incorrect assumption
The test case that concerns `git rebase -Xsubtree` (with the default rebase backend, not with `--preserve-merges`) starts out with a pre-rebase commit history that begins with a commit that introduces three files: master1.t, master2.t and master3.t. This commit was generated by passing a subtree merge commit through `git filter-branch --subdirectory-filter`, so it looks as if this commit really introduces all those files. The commit history onto which this commit is then rebased, however, introduced those files in individual commits. For that reason, the rebase will fail, it _must_ fail, because the first `pick` results in no changes to be committed. Let's fix the test case to expect exactly this situation. With this change, we can mark the original bug that this test case tried to demonstrate as fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5321-pack-large-objects.sh')
0 files changed, 0 insertions, 0 deletions