Re: On automated commits

On 6/27/24 6:43 AM, Alan Modra via Gdb wrote:
> On Thu, Jun 27, 2024 at 09:23:20AM -0400, Paul Koning wrote:
>>
>>
>>> On Jun 26, 2024, at 9:32 PM, Alan Modra <[email protected]> wrote:
>>>
>>> On Wed, Jun 26, 2024 at 11:17:04AM -0700, Joel Brobecker wrote:
>>>>> I personally have never liked these automated commits, and I can't
>>>>> recall ever using the date they provide.
>>>>>
>>>>> I also don't believe these dates are used here at AdaCore.
>>>>>
>>>>> So +1 from me for removing these.
>>>>
>>>> Same here.
>>>>
>>>> I know that some people found them useful, but I don't remember why
>>>> unfortunately.
>>>
>>> The date is useful when looking at bug reports from people who might
>>> be building from development sources.
>>
>> So why not have the build procedure pick up the last commit date, if building in a Git sandbox?  That's easy enough to arrange.  Similarly, it could pick up the identifier (SHA hash) of that last commit to make it entirely unambiguous.
> 
> I wasn't saying the way we do things now is the only way, just
> explaining why the date is useful.  "git show -s --oneline @{u}" or
> similar would be good too, but let's make sure we report upstream
> commits not local ones.

If someone has local commits, it's kind of on them to know what upstream
commit those local commits are on top of.  In my general experience using
the relevant VCS identifier (git hash, svn revision, etc.) is usually the
most useful thing to have for tracking down issues.  In the case of a
regression on trunk it saves you the step of matching a date to a git hash
so you can start a bisect.

(Also, the date bump commits are indeed noisy, especially on release
branches, but there's also probably some way to filter commits shown by
git log to avoid them (e.g. omitting commits for the file in question)).

-- 
John Baldwin