Junio C Hamano <junkio@xxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>
> + fprintf(stderr, "warning: Log %s only goes back to %s.\n",
> + logfile, show_rfc2822_date(date, tz));
> + return 0;
>
> I am not sure about this part. If the oldest log entry was 3
> hours ago, the second oldest 2 hours ago, we can tell during
> that one hour period the ref was at that point. If the user
> asked "ref as of four hours ago", and if the oldest log entry
> had old SHA1 that is not 0{40} (because the log was not enabled
> before that record), it might make more sense to give that back.
If I understand my own code here what I'm doing is walking back
in the log file, realizing I fell off the first line of it, then
loading the old ref from the first line. This is the oldest ref
I can find so I return it as a valid ref to the caller but I'm
printing out this warning to tell the user that the oldest point
in time I found in the log is effectively the update date as I have
no idea when that old sha1 first became the value of the ref.
So I think I'm doing what you are expecting here. The log will start
with the value in the ref at the time the log started, not 0{40}
and that value is what gets returned when we have this warning
come out.. That's the best anyone can expect...
> Also I wonder how much complexity would we suffer and how much
> efficiency would we gain if we binary search the logdata (the
> committer info is variable length, so you would need to resync
> in each step).
I thought about doing this but did not think it would be worth the
effort (either developer to code or CPU to execute) at this point
in time. I don't think users will be pulling refs from the log very
often and if they are they will probably be pulling from recent time,
not very far back. Thus starting at the end and walking back is
probably "good enough".
But if it proves to be too slow in practice I'm sure I can come up
with a faster way to walk through the log. :-)
--
Shawn.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html