Re: Bug: rebase -i creates committer time inversions on 'reword'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux