Am 15.04.2018 um 23:35 schrieb Junio C Hamano:
Ah, do you mean we have an internal sequence like this, when "rebase
--continue" wants to conclude an edit/reword?
Yes, it's only 'reword' that is affected, because then subsequent picks
are processed by the original process.
- we figure out the committer ident, which grabs a timestamp and
cache it;
- we spawn "commit" to conclude the stopped step, letting it record
its beginning time (which is a bit older than the above) or its
ending time (which is much older due to human typing speed);
Younger in both cases, of course. According to my tests, we seem to pick
the beginning time, because the first 'reword'ed commit typically has
the same timestamp as the preceding picks. Later 'reword'ed commits have
noticably younger timestamps.
- subsequent "picks" are made in the same process, and share the
timestamp we grabbed in the first step, which is older than the
second one.
I guess we'd want a mechanism to tell ident.c layer "discard the
cached one, as we are no longer in the same automated sequence", and
use that whenever we spawn an editor (or otherwise go interactive).
Frankly, I think that this caching is overengineered (or prematurly
optimized). If the design requires that different callers of datestamp()
must see the same time, then the design is broken. In a fixed design,
there would be a single call of datestamp() in advance, and then the
timestamp, which then obviously is a very important piece of data, would
be passed along as required.
-- Hannes
