summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2008-07-08 00:38:54 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2008-07-08 13:57:27 -0700
commitd1a4489a56e2ceac8e7dc9eb277a9f36fec725c5 (patch)
tree93dbc7e11d83ec4083524daa0fa537a5857190f9 /Documentation
parentDocumentation: fix broken "linkgit" links (diff)
downloadtgif-d1a4489a56e2ceac8e7dc9eb277a9f36fec725c5.tar.xz
avoid null SHA1 in oldest reflog
When the user specifies a ref by a reflog entry older than one we have (e.g., "HEAD@{20 years ago"}), we issue a warning and give them the "from" value of the oldest reflog entry. That is, we say "we don't know what happened before this entry, but before this we know we had some particular SHA1". However, the oldest reflog entry is often a creation event such as clone or branch creation. In this case, the entry claims that the ref went from "00000..." (the null sha1) to the new value, and the reflog lookup returns the null sha1. While this is technically correct (the entry tells us that the ref didn't exist at the specified time) it is not terribly useful to the end user. What they probably want instead is "the oldest useful sha1 that this ref ever had". This patch changes the behavior such that if the oldest ref would return the null sha1, it instead returns the first value the ref ever had. We never discovered this problem in the test scripts because we created "fake" reflogs that had only a specified segment of history. This patch updates the tests with a creation event at the beginning of history. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions