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.