Jeff King <peff@xxxxxxxx> writes:
> On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
>
>> Complexity: Was that due to replace refs? Other than that, it seemed to
>> be simple: max(parent generation numbers)+1.
>
> Calculating them is simple. Caching and storage is the bigger question.
Yes, also having to handle the ones whose generation numbers haven't
been computed yet adds to the complexity.
This one, and $gmane/264101, are a few instances of this known issue
raised here recently. I have been wondering if we can do something
along the following (these are not alternatives) as a cheaper
workaround:
(1) Introduce '--skewed-timestamps[=(allow|warn|reject)' to all
commands that create new commit objects. If the committer
timestamp being used is older than any of the parent commits,
"warn" or "reject" depending on the setting.
Make 'reject' the default for commands that are purely local
(i.e. recording your own progress by cherry-picking,
committing, rebasing, reverting, etc.) and 'warn' the default
for commands that merge other peoples' history that you may
lack the power to rewind and correct (e.g. 'pull' and 'merge'
from remote tracking refs).
(2) Compute a bitmap whose timestamps are suspect when we pack to
mark commits. When revision.c:limit_list() tries to see if
there still are interesting commits, an UNINTERESTING commit
marked as such shouldn't be counted as "not interesting because
it is old enough". Use the same hint in the walker used in
"describe --contains".
--
To unsubscribe from this list: 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