Re: [PATCH] name-rev: test showing failure with non-monotonic commit dates

From: Jacob Keller <jacob.keller@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee <derrickstolee@github.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] name-rev: test showing failure with non-monotonic commit dates
Date: Sun, 27 Feb 2022 14:05:15 -0800	[thread overview]
Message-ID: <CA+P7+xoaHtHMxE_RVBRyhOqVfuP_1s+2NGpGDo_eKfb25_ty7g@mail.gmail.com> (raw)
In-Reply-To: <xmqq1r03zl9z.fsf@gitster.g>

On Tue, Feb 15, 2022 at 4:51 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> In "name-rev [--tags] C", we look for a tag to use in describing the
> given commit C as an ancestry path starting at the tag T (e.g. T~4,
> T~2^2).  There can be multiple such tags (e.g. it is likely that a
> commit that is v1.0~2 is also reachable from tag v2.0, even though
> it would require more hops).  We try to and find a tag that gives
> the "simplest" path.  For that purpose, it is no use to consider any
> tag that is not a descendant of the given commit, because doing an
> ancestry traversal starting from such a tag will never reach the
> commit.  In a world where everybody's clock is in sync, if commit
> was made at time X, any tag that was made before time X will not be
> a descendant of the commit, so we do not add such a tag to the
> candidate pool.
>
> I think the idea of "cutoff" heuristic is exactly what generation
> numbers can improve, in an imperfect world where there are imperfect
> clocks.

Yep. I have a patch that will implement this behavior based on
Derrick's suggestion.

Thanks,
Jake