Re: [Boost-testing] revisions and timestamps

Subject: Re: [Boost-testing] revisions and timestamps
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-21 13:44:10

Le 20/01/14 01:07, Daniel James a écrit :
> On 19 January 2014 22:57, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Le 19/01/14 19:47, Joaquin M Lopez Munoz a écrit :
>>
>>> Now that regression testers go against Github, the reported revision # is
>>> a
>>> bunch of random hexadecimal digits (for instance, "rev 29e219") rather
>>> than
>>> an increasing number like in SVN, which makes it very hard to determine at
>>> a
>>> glance if a particular test pre- or postdates a revision one's interested
>>> in.
>>>
>>> I see also that the reported timestamp, which looks like
>>>
>>>    "Sun, 19 Jan 2014 06:08:04 +0000"
>>>
>>> seems to indicate the time where the result file was generated, which is
>>> of little use. Woukd it be hard to adapt the scripts so that the reported
>>> date is instead that associated to the revision? Is this info available to
>>> the regression tester? The change, if possible, would render regression
>>> tables much more usable.
>>>
>>>
>> Hi Joaquin,
>>
>> I suspect that the situation is even worst. I have the impression that the
>> date associated to a revision corresponds to the date the revision was
>> committed locally, not when it was pushed to develop or master. Can some of
>> the Git experts confirm my suspicion?
> The date would be from the super project. Updates to use the latest
> version of a module are automated and pushed almost immediately after
> a commit, so the dates for automatic commits should be reliable.
Github is showing the date of the local commit. What I need to do to 
make GitHub show the remote commit?
>
> There might be a little confusion if someone has made manual changes
> to the super project. One thing we could do is use the committer date,
> rather than the author date. This means that if a change is committed
> after it was originally made (e.g. by cherry-picking) the date of the
> commit is used, rather than the original date. Even if this is pushed
> a while after the commit, the date would be fine for comparing with
> other dates in the history - since a push must include a commit that
> was made after the current commit on github (unless it's forced, but
> the tested branches super project should never have a forced push).
> Merges might be tricky to interpret, but generally it shouldn't be
> problematic.
>
> And we want to move as many files as possible out of the super
> project, so that there should be less manual changes in the future.
>
> We can get the committer date for a revision using:
>
> git show --pretty="format:%cd" --no-patch HEAD

With my git installation I'm getting

git show --pretty="format:%cd" --no-patch HEAD
fatal: unrecognized argument: --no-patch

git --version
git version 1.7.7.5 (Apple Git-26)

Should I update to a newer git version?
>
> (HEAD can be replaced with the hash or whatever), although I wouldn't
> be surprised if there's a better way to do that.I guess this would
> have to be done in the python scripts and would need to deal with
> timezones.
Best,
Vicente