avoid null SHA1 in oldest reflog
authorJeff King <peff@peff.net>
Tue, 8 Jul 2008 04:38:54 +0000 (00:38 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 8 Jul 2008 20:57:27 +0000 (13:57 -0700)
commitd1a4489a56e2ceac8e7dc9eb277a9f36fec725c5
tree93dbc7e11d83ec4083524daa0fa537a5857190f9
parentea449615d89888a56f1b62c59de6a2668185d11a
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>
refs.c
t/t1400-update-ref.sh