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

[Mike Hommey <mh@glandium.org>]

On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
> 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).

Please note that a common cause (for me, at least) of skewed timestamps
is importing from a foreign VCS.

Mike