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

On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:

quoted

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