Re: [PATCH v2] bisect: Honor log.date

[Junio C Hamano <gitster@pobox.com>]

Peter Krefting <peter@softwolves.pp.se> writes:

> In this particular case, calling "git show" is really the last thing
> we want to do; so if we can move the cleanup that happens after it
> (that ends the bisect), it should be able to just take over the
> current process with a call to show, without needing to re-exec.

The cmd_foo() functions are also expected to either return to their
callers or call exit() themselves, and it is true that as the very
last step before giving the control back to the end-user in the
current "bisect" process, we could make an internal call to
cmd_foo() and let it exit with its own exit status.

But that is only the latter half of a story.

The cmd_show() (or any cmd_foo() in general) function expects to
start from within a pristine environment.  Calling them _after_
somebody else (in this case everything called from cmd_bisect())
clobbered the global state may or may not work (and in general we
should assume it would not work) correctly.

The outline of the envisioned end state of libification I gave was
about an arrangement to ensure that we can give such an pristine
state when we make a call to such "top level" entry point of "foo"
command (in this case, "show"), from a different command (in this
case, "bisect").  It is very much orthogonal to what you are talking
about, I think.  We need both.

> And calling back to the libification question, I would see this part
> of the bisect command to be something that would run *on top of* the
> library (with possibly an API to poke bad/good states into it), so I
> don't think that objection holds for this particular case.

There was no objection.  I was just pointing out that the infrastructure
is not ready to do so.