Re: git out-of-order commit (was Re: [PATCH] Fortran: Remove unused declaration)

[Carlos O'Donell <carlos@redhat.com>]

On 1/19/23 23:26, Bernhard Reutner-Fischer wrote:
> On 19 January 2023 20:39:08 CET, Jason Merrill <jason@redhat.com> wrote:
>> On Sat, Nov 12, 2022 at 4:24 PM Harald Anlauf via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> Am 12.11.22 um 22:05 schrieb Bernhard Reutner-Fischer via Gcc-patches:
>>>> This function definition was removed years ago, remove it's prototype.
>>>>
>>>> gcc/fortran/ChangeLog:
>>>>
>>>>       * gfortran.h (gfc_check_include): Remove declaration.
>>>> ---
>>>>   gcc/fortran/gfortran.h | 1 -
>>>>   1 file changed, 1 deletion(-)
>>>> ---
>>>> Regtests cleanly, ok for trunk?
>>>>
>>>> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
>>>> index c4deec0d5b8..ce3ad61bb52 100644
>>>> --- a/gcc/fortran/gfortran.h
>>>> +++ b/gcc/fortran/gfortran.h
>>>> @@ -3208,7 +3208,6 @@ int gfc_at_eof (void);
>>>>   int gfc_at_bol (void);
>>>>   int gfc_at_eol (void);
>>>>   void gfc_advance_line (void);
>>>> -int gfc_check_include (void);
>>>>   int gfc_define_undef_line (void);
>>>>
>>>>   int gfc_wide_is_printable (gfc_char_t);
>>>
>>> OK, thanks.
>>
>> Somehow this was applied with a CommitDate in 2021, breaking scripts
>> that assume monotonically increasing CommitDate.  Anyone know how that
>> could have happened?
> 
> Sorry for that.
> I think i cherry-picked this commit to master before pushing it, not 100% sure though.
> What shall we do now?

I doubt a cherry-pick did this, we cherry pick often in glibc and the
commit is added to the top of checkout and the commit date updated.

There isn't anything we can do now.

I was recently made aware that --since-as-filter= was added specifically to address this issue.

https://patchwork.kernel.org/project/git/patch/YlnYDgZRzDI87b/z@vmiklos.hu/
~~~
This is similar to --since, but it will filter out not matching commits,
rather than stopping at the first not matching commit.

This is useful if you e.g. want to list the commits from the last year,
but one odd commit has a bad commit date and that would hide lots of
earlier commits in that range.

The behavior of --since is left unchanged, since it's valid to depend on
its current behavior.

Signed-off-by: Miklos Vajna <vmiklos@vmiklos.hu>
~~~

"but one odd commit has a bad commit date" :-)

We should try to avoid commits like this because they really complicate
any date-based analysis tooling, and --since-as-filter is fairly new.

-- 
Cheers,
Carlos.