Re: git describe --contains doesn't work properly for a commit

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

Jeff King <peff@peff.net> 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".