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: 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: Mon, 14 Feb 2022 14:07:23 -0800	[thread overview]
Message-ID: <CA+P7+xrN0zPWfxO1roWzR+MBHntTv8jr9OGdNcN9RPA=ebK24A@mail.gmail.com> (raw)
In-Reply-To: <xmqqr18515jr.fsf@gitster.g>

On Mon, Feb 14, 2022 at 1:50 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Jacob Keller <jacob.e.keller@intel.com> writes:
>
> > From: Jacob Keller <jacob.keller@gmail.com>
> >
> > If a commit in a sequence of linear history has a non-monotonically
> > increasing commit timestamp, git name-rev will not properly name the
> > commit.
> >
> > However, if you use --annotate-stdin then the commit does actually get
> > picked up and named properly.
>
> IIRC, this is to be expected.
>

Right. I figured this is somehow expected behavior...

> When preparing to answer --annotate-stdin request, the command has
> to dig down to the root of the history, which would be too expensive
> in some repositories and wants to stop traversal early when it knows
> particular commits it needs to describe.
>

And this method of cutting the search relies on monotonic commit times right?

Is there any other method we could use (commit graph?) or perhaps to
add an option so that you could go "git name-rev --no-cutoff <commid
id>"? That would potentially allow working around this particular
problem on repositories where its known to be problematic.

Alternatively is there some other way to apply the cutoff heuristic
only in some cases? I get the sense this is intended to allow cutting
off merged branches? i.e. not applying it when history is linear? I'd
have to study it further but the existing algorithm seems to break
because as it goes up the history it has found an "older" commit, so
it stops trying to blame that line...?

> Dscho?  I think this is pretty much a fundamental part of the
> initial version added by bd321bcc (Add git-name-rev, 2005-10-26) and
> kept that way to this day, I think.
>

The reason we ended up with non-monotonic commit timestamps is a bit
strange, and at least going forward I can remove the cause. However
the history I deal with already has this, so perhaps a simple
"--no-cutoff" option would be sufficient? This would allow getting the
equivalent behavior to annotate-stdin without needing to script it
myself.

Thanks,
Jake