That's exactly what I did ;)
> On Aug 15, 2019, at 8:52 AM, Mechtilde <[email protected]> wrote:
>
> Hello,
>
> we should commit to trunk and if that code should also be in 42x or 417
> we can cherry- pick the commit.
>
> regards
>
> Mechtilde
>
> Am 15.08.19 um 14:02 schrieb Jim Jagielski:
>> Anyone have issues if we also commit to the 42X and 417 branches?
>>
>>> On Aug 15, 2019, at 1:03 AM, Peter Kovacs <[email protected]> wrote:
>>>
>>> I pushed the change to gitbox trunk.
>>>
>>> On 15.08.19 00:15, Kay Schenk wrote:
>>>> On Wed, Aug 14, 2019 at 3:07 PM Matthias Seidel
>>>> <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Kay,
>>>>>
>>>>> Am 15.08.19 um 00:02 schrieb Kay Schenk:
>>>>>> On Wed, Aug 14, 2019 at 1:24 PM Marcus <[email protected]> wrote:
>>>>>>
>>>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <[email protected]>
>>>>>>> wrote:
>>>>>>>>> Matthias Seidel wrote:
>>>>>>>>>> We already have the build id, the build
>>>>>>>>>> date and now the git hash (which is a unique link to the last commit
>>>>> it
>>>>>>>>>> was based on)
>>>>>>>>>> This is how we did it with SVN, why should we change it?
>>>>>>>>> Because we are dropping information. The SVN revisions are always
>>>>>>> increasing, and thus (independent on the build date, which can be at any
>>>>>>> moment) I can compare two builds and retain information on which came
>>>>> first.
>>>>>>>>> With git of course this doesn't hold, i.e., you cannot say which
>>>>> commit
>>>>>>> came earlier between abcd1234 and 5678abcd. So I see some added value
>>>>> if we
>>>>>>> enrich it this way.
>>>>>>>> Is that needed though? I had thought the basic reason for having the
>>>>> SVN
>>>>>>> ID is that the end-user knows, for sure, which SVN revision their app
>>>>> was
>>>>>>> built from.
>>>>>>>
>>>>>>> it's unrealistic that the commit was done, e.g., today but the build
>>>>>>> weeks later. So, Git hash and build date is not done at the exact same
>>>>>>> date and time. But nearly. And here it think it's sufficiant.
>>>>>>>
>>>>>>> But when we decide to prefix the hash with a date value it's OK for me,
>>>>>>> too.
>>>>>>>
>>>>>>> Marcus
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>
>>>>>>>
>>>>>> I think the date and hash should be displayed in the "build information"
>>>>>> screen as the revision information was previously. In Jim's sample
>>>>> display,
>>>>>> although the date is displayed, there is no indication of actual
>>>>> "revision"
>>>>>> (hash).
>>>>> This is simply because the code we are discussing about is still not
>>>>> committed.
>>>>>
>>>>> I applied Peters patch and it looks like this:
>>>>>
>>>>>
>>>>> https://www.dropbox.com/s/tkal1y9b09vrhse/VirtualBox_Windows%2010%20AOO-Build_14_08_2019_16_14_33.png?dl=0
>>>>>
>>>>> Matthias
>>>>>
>>>> OK. Good.
>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> <mailto:[email protected]>
>>> <mailto:[email protected]
>>> <mailto:[email protected]>>
>>> For additional commands, e-mail: [email protected]
>>> <mailto:[email protected]>
>>> <mailto:[email protected]
>>> <mailto:[email protected]>>
>>
>
> --
> Mechtilde Stehmann
> ## Apache OpenOffice
> ## Freie Office Suite für Linux, MacOSX, Windows
> ## Debian Developer
> ## PGP encryption welcome
> ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F