summaryrefslogtreecommitdiff
path: root/t/t4135/add-plain.diff
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-07-05 03:57:37 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-07-05 10:34:00 -0700
commit2272d3e5426a65f3fdf456f8e1bfbea40d037a59 (patch)
treef63da85a887313c6bd2f1b66262ac0bada76fb0a /t/t4135/add-plain.diff
parentGit 2.13.2 (diff)
downloadtgif-2272d3e5426a65f3fdf456f8e1bfbea40d037a59.tar.xz
reflog-walk: skip over double-null oid due to HEAD rename
Since 39ee4c6c2f (branch: record creation of renamed branch in HEAD's log, 2017-02-20), a rename on the currently checked out branch will create two entries in the HEAD reflog: one where the branch goes away (switching to the null oid), and one where it comes back (switching away from the null oid). This confuses the reflog-walk code. When walking backwards, it first sees the null oid in the "old" field of the second entry. Thanks to the "root commit" logic added by 71abeb753f (reflog: continue walking the reflog past root commits, 2016-06-03), we keep looking for the next entry by scanning the "new" field from the previous entry. But that field is also null! We need to go just a tiny bit further, and look at its "old" field. But with the current code, we decide the reflog has nothing else to show and just give up. To the user this looks like the reflog was truncated by the rename operation, when in fact those entries are still there. This patch does the absolute minimal fix, which is to look back that one extra level and keep traversing. The resulting behavior may not be the _best_ thing to do in the long run (for example, we show both reflog entries each with the same commit id), but it's a simple way to fix the problem without risking further regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4135/add-plain.diff')
0 files changed, 0 insertions, 0 deletions