summaryrefslogtreecommitdiff
path: root/t/t4034/perl/expect
diff options
context:
space:
mode:
authorLibravatar Denton Liu <liu.denton@gmail.com>2021-01-07 02:36:59 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2021-01-11 14:13:50 -0800
commit6436a20284f33d42103cac93bd82e65bebb31526 (patch)
treecdf5f66dce357743da868af7f898cee3f306f6a7 /t/t4034/perl/expect
parentrefs: factor out set_read_ref_cutoffs() (diff)
downloadtgif-6436a20284f33d42103cac93bd82e65bebb31526.tar.xz
refs: allow @{n} to work with n-sized reflog
This sequence works $ git checkout -b newbranch $ git commit --allow-empty -m one $ git show -s newbranch@{1} and shows the state that was immediately after the newbranch was created. But then if you do $ git reflog expire --expire=now refs/heads/newbranch $ git commit --allow=empty -m two $ git show -s newbranch@{1} you'd be scolded with fatal: log for 'newbranch' only has 1 entries While it is true that it has only 1 entry, we have enough information in that single entry that records the transition between the state in which the tip of the branch was pointing at commit 'one' to the new commit 'two' built on it, so we should be able to answer "what object newbranch was pointing at?". But we refuse to do so. Make @{0} the special case where we use the new side to look up that entry. Otherwise, look up @{n} using the old side of the (n-1)th entry of the reflog. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4034/perl/expect')
0 files changed, 0 insertions, 0 deletions