Hi Jim,

Am 15.08.19 um 16:58 schrieb Jim Jagielski:
> That's exactly what I did ;)

If you do:

git cherry-pick -x <Hash>

you additionally get a cross-reference to the original commit.

(Thanks Mechtilde for that info!)

Matthias

>
>> On Aug 15, 2019, at 8:52 AM, Mechtilde <o...@mechtilde.de> 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 <pe...@apache.org> 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 
>>>>> <matthias.sei...@hamburg.de>
>>>>> wrote:
>>>>>
>>>>>> Hi Kay,
>>>>>>
>>>>>> Am 15.08.19 um 00:02 schrieb Kay Schenk:
>>>>>>> On Wed, Aug 14, 2019 at 1:24 PM Marcus <marcus.m...@wtnet.de> wrote:
>>>>>>>
>>>>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pesce...@apache.org>
>>>>>>>> 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: dev-unsubscr...@openoffice.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>> 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: dev-unsubscr...@openoffice.apache.org 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org> 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org 
>>>> <mailto:dev-unsubscr...@openoffice.apache.org>>
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>>> <mailto:dev-h...@openoffice.apache.org> 
>>>> <mailto:dev-h...@openoffice.apache.org 
>>>> <mailto:dev-h...@openoffice.apache.org>>
>> -- 
>> 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
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to