You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kovacs <Pe...@Apache.org> on 2019/08/11 17:40:18 UTC
get Revision from Git (short Hash)
Hi all,
I have adjusted the Function DetectRevisionId in
main/solenv/bin/modules/SvnRevision.pm to return the short hash when
executed in a git repository.
If it is not a git repository, it will fallback to the SVN logic. The
short hash includes a newline. I am not sure if that will make any trouble.
I have attached the patch. Please review. I could not test a complete
build I have some building issues. (I will send some separated mails.)
Also I have not checked in because of the lacking N2N test, and since I
do not know what this newline does.
All the Best
Peter
Re: get Revision from Git (short Hash)
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, this is what AOO 4.1.7 looks like:
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <pe...@apache.org>.
We need to check if local commit dates change with pull or push to gitbox.
I would prefer git commit number over dates, drawn from gitbox as additional information.
Am 14. August 2019 17:03:04 MESZ schrieb Matthias Seidel <ma...@hamburg.de>:
>Hi Andrea,
>
>Am 14.08.19 um 16:51 schrieb Andrea Pescetti:
>> 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.
>
>OK, then we could do it like Peter suggested and add the (commit) date
>after the Git hash.
>
>Something like this (in case of my build):
>
>AOO420m2(Build:9821) - Rev. 20ef23374c - Mon Aug 12 21:11:24 2019
>+0200
>2019-08-13 15:58 - CYGWIN_NT-10.0 x86_64 - Development Test Build
>
>Matthias
>
>>
>> Regards,
>> Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Andrea,
Am 14.08.19 um 16:51 schrieb Andrea Pescetti:
> 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.
OK, then we could do it like Peter suggested and add the (commit) date
after the Git hash.
Something like this (in case of my build):
AOO420m2(Build:9821) - Rev. 20ef23374c - Mon Aug 12 21:11:24 2019 +0200
2019-08-13 15:58 - CYGWIN_NT-10.0 x86_64 - Development Test Build
Matthias
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
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 <oo...@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 <ma...@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 <ma...@wtnet.de> wrote:
>>>>>>>
>>>>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org> <mailto:dev-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org>>
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org <ma...@openoffice.apache.org> <mailto:dev-help@openoffice.apache.org <ma...@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
>
Re: get Revision from Git (short Hash)
Posted by Jim Jagielski <ji...@jaguNET.com>.
That's exactly what I did ;)
> On Aug 15, 2019, at 8:52 AM, Mechtilde <oo...@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 <ma...@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 <ma...@wtnet.de> wrote:
>>>>>>
>>>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org> <mailto:dev-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org>>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org <ma...@openoffice.apache.org> <mailto:dev-help@openoffice.apache.org <ma...@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
Re: get Revision from Git (short Hash)
Posted by Mechtilde <oo...@mechtilde.de>.
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 <ma...@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 <ma...@wtnet.de> wrote:
>>>>>
>>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org <ma...@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
Re: get Revision from Git (short Hash)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <ma...@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 <ma...@wtnet.de> wrote:
>>>>
>>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org <ma...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org <ma...@openoffice.apache.org>
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <Pe...@Apache.org>.
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 <ma...@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 <ma...@wtnet.de> wrote:
>>>
>>>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Aug 14, 2019 at 3:07 PM Matthias Seidel <ma...@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 <ma...@wtnet.de> wrote:
> >
> >> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
> >>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@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.
>
> >
>
>
--
"And in the end, only kindness matters."
-- Jewel, "Hands"
________________________________________
MzK
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Kay,
Am 15.08.19 um 00:02 schrieb Kay Schenk:
> On Wed, Aug 14, 2019 at 1:24 PM Marcus <ma...@wtnet.de> wrote:
>
>> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>>>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@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
>
Re: get Revision from Git (short Hash)
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Aug 14, 2019 at 1:24 PM Marcus <ma...@wtnet.de> wrote:
> Am 14.08.19 um 22:02 schrieb Jim Jagielski:
> >> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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).
--
"And in the end, only kindness matters."
-- Jewel, "Hands"
________________________________________
MzK
Re: get Revision from Git (short Hash)
Posted by Marcus <ma...@wtnet.de>.
Am 14.08.19 um 22:02 schrieb Jim Jagielski:
>> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Aug 14, 2019, at 10:51 AM, Andrea Pescetti <pe...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Andrea Pescetti <pe...@apache.org>.
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.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Peter, all,
Am 14.08.19 um 12:16 schrieb Peter Kovacs:
> First we are already on git. The switch has already been completed. If you are unsatisfied from the plantings then that is fine for me.
>
> I think you have only to modify the print git command from my patch to add the date. Also I have a variant ready that returns the git-svn-id if on is there.
I don't think this is necessary: 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):
https://www.dropbox.com/s/tkal1y9b09vrhse/VirtualBox_Windows%2010%20AOO-Build_14_08_2019_16_14_33.png?dl=0
This is how we did it with SVN, why should we change it?
@Peter:
I made a logical mistake regarding the git-svn-id, so I think your first
patch is totally sufficient.
Regards,
Matthias
>
> Please see my patch earlier in the thread.
>
> Am 14. August 2019 10:28:59 MESZ schrieb Andrea Pescetti <pe...@apache.org>:
>> Dave Fisher wrote:
>>> Put another way does switching to Git require careful discussion of
>> update scenarios?
>>
>> No. Updates use version numbers, that are defined (to some people, this
>>
>> may be a bug rather than a feature!) explicitly in configuration files;
>>
>> so they are not linked at all to the revision control system in use.
>>
>> The revision number/hash is only significant for dev builds, where the
>> update mechanism does not apply.
>>
>> Regards,
>> Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <pe...@apache.org>.
First we are already on git. The switch has already been completed. If you are unsatisfied from the plantings then that is fine for me.
I think you have only to modify the print git command from my patch to add the date. Also I have a variant ready that returns the git-svn-id if on is there.
Please see my patch earlier in the thread.
Am 14. August 2019 10:28:59 MESZ schrieb Andrea Pescetti <pe...@apache.org>:
>Dave Fisher wrote:
>> Put another way does switching to Git require careful discussion of
>update scenarios?
>
>No. Updates use version numbers, that are defined (to some people, this
>
>may be a bug rather than a feature!) explicitly in configuration files;
>
>so they are not linked at all to the revision control system in use.
>
>The revision number/hash is only significant for dev builds, where the
>update mechanism does not apply.
>
>Regards,
> Andrea.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Andrea Pescetti <pe...@apache.org>.
Dave Fisher wrote:
> Put another way does switching to Git require careful discussion of update scenarios?
No. Updates use version numbers, that are defined (to some people, this
may be a bug rather than a feature!) explicitly in configuration files;
so they are not linked at all to the revision control system in use.
The revision number/hash is only significant for dev builds, where the
update mechanism does not apply.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Aug 13, 2019, at 11:51 PM, Andrea Pescetti <pe...@apache.org> wrote:
>
>> On 13/08/2019 Matthias Seidel wrote:
>> Regarding the short git hash (vs. long git hash):
>> I can live with it. But if there is something fundamentally wrong with using it (in our About dialog and on our download page) the Git gurus should speak up *now*. ;-)
>
> Short is fine. I would honestly prefer something that is increasing with time, so something like "20190814-abcd123" as this is more informative (note I mean the date of the specific commit, not the build date; the two will be different in general).a
>
> I can take care of this when I have time for looking into it in case.
Are we discussing logic for the update process?
If so and switching to Git is one answer encoding a known progression and following that to check for updates?
Put another way does switching to Git require careful discussion of update scenarios?
Regards,
Dave
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Andrea Pescetti <pe...@apache.org>.
On 13/08/2019 Matthias Seidel wrote:
> Regarding the short git hash (vs. long git hash):
> I can live with it. But if there is something fundamentally wrong with
> using it (in our About dialog and on our download page) the Git gurus
> should speak up *now*. ;-)
Short is fine. I would honestly prefer something that is increasing with
time, so something like "20190814-abcd123" as this is more informative
(note I mean the date of the specific commit, not the build date; the
two will be different in general).
I can take care of this when I have time for looking into it in case.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Peter,
Am 11.08.19 um 20:36 schrieb Peter Kovacs:
> Okay I am really out of practice with Perl.
>
> I fixed an error in the script. I used the wrong command to escape to
> the shell. -.-
>
> please find an updated patch.
Thanks! I am just building 4.2.0 for Windows with your patch applied.
> On 11.08.19 19:57, Peter Kovacs wrote:
>> Ok. I remove it.
>>
>> On 11.08.19 19:56, Marcus wrote:
>>> Am 11.08.19 um 19:40 schrieb Peter Kovacs:
>>>> I have adjusted the Function DetectRevisionId in
>>>> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
>>>> executed in a git repository.
>>>>
>>>> If it is not a git repository, it will fallback to the SVN logic.
One addition:
If it is a Git repository it should first look for a git-svn-id. Only if
it isn't present it should use the git hash.
This way it would be possible to build older revisions from Git with the
SVN Revision (via git-svn-id).
Only newer revisions (after the switch to Git) would use the git hash.
>>>> The
>>>> short hash includes a newline. I am not sure if that will make any
>>>> trouble.
Regarding the short git hash (vs. long git hash):
I can live with it. But if there is something fundamentally wrong with
using it (in our About dialog and on our download page) the Git gurus
should speak up *now*. ;-)
Regards,
Matthias
>>>>
>>>> I have attached the patch. Please review. I could not test a complete
>>>> build I have some building issues. (I will send some separated mails.)
>>>>
>>>> Also I have not checked in because of the lacking N2N test, and since I
>>>> do not know what this newline does.
>>> thanks for the piece of code. Any sideeffects need to be tested of
>>> course.
>>>
>>> One problem I could image is the About dialog. Showing the Git hash
>>> with a newline would be not suitable.
>>>
>>> Any other problem would be in the build system itself I thin.
>>>
>>> So, avoiding the newline would be great.
>>>
>>> Marcus
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Matthias Seidel <ma...@hamburg.de>.
Hi Peter,
Am 13.08.19 um 19:14 schrieb Peter Kovacs:
> I try to add the feature. I currently do not know how to check/retireve
> the git-svn-id. Need to search for it.
That is the part you replaced... ;-)
Instead, just add your code without removing the old.
Regards,
Matthias
>
> On 13.08.19 16:46, Matthias Seidel wrote:
>> Hi Peter,
>>
>> Am 11.08.19 um 20:36 schrieb Peter Kovacs:
>>> Okay I am really out of practice with Perl.
>>>
>>> I fixed an error in the script. I used the wrong command to escape to
>>> the shell. -.-
>>>
>>> please find an updated patch.
>> Thanks! I am just building 4.2.0 for Windows with your patch applied.
>>> On 11.08.19 19:57, Peter Kovacs wrote:
>>>> Ok. I remove it.
>>>>
>>>> On 11.08.19 19:56, Marcus wrote:
>>>>> Am 11.08.19 um 19:40 schrieb Peter Kovacs:
>>>>>> I have adjusted the Function DetectRevisionId in
>>>>>> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
>>>>>> executed in a git repository.
>>>>>>
>>>>>> If it is not a git repository, it will fallback to the SVN logic.
>> One addition:
>>
>> If it is a Git repository it should first look for a git-svn-id. Only
>> if it isn't present it should use the git hash.
>>
>> This way it would be possible to build older revisions from Git with
>> the SVN Revision (via git-svn-id).
>> Only newer revisions (after the switch to Git) would use the git hash.
>>
>>>>>> The
>>>>>> short hash includes a newline. I am not sure if that will make any
>>>>>> trouble.
>> Regarding the short git hash (vs. long git hash):
>>
>> I can live with it. But if there is something fundamentally wrong with
>> using it (in our About dialog and on our download page) the Git gurus
>> should speak up *now*. ;-)
>>
>> Regards,
>>
>> Matthias
>>
>>>>>> I have attached the patch. Please review. I could not test a complete
>>>>>> build I have some building issues. (I will send some separated mails.)
>>>>>>
>>>>>> Also I have not checked in because of the lacking N2N test, and since I
>>>>>> do not know what this newline does.
>>>>> thanks for the piece of code. Any sideeffects need to be tested of
>>>>> course.
>>>>>
>>>>> One problem I could image is the About dialog. Showing the Git hash
>>>>> with a newline would be not suitable.
>>>>>
>>>>> Any other problem would be in the build system itself I thin.
>>>>>
>>>>> So, avoiding the newline would be great.
>>>>>
>>>>> Marcus
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <Pe...@Apache.org>.
I try to add the feature. I currently do not know how to check/retireve
the git-svn-id. Need to search for it.
On 13.08.19 16:46, Matthias Seidel wrote:
>
> Hi Peter,
>
> Am 11.08.19 um 20:36 schrieb Peter Kovacs:
>> Okay I am really out of practice with Perl.
>>
>> I fixed an error in the script. I used the wrong command to escape to
>> the shell. -.-
>>
>> please find an updated patch.
> Thanks! I am just building 4.2.0 for Windows with your patch applied.
>> On 11.08.19 19:57, Peter Kovacs wrote:
>>> Ok. I remove it.
>>>
>>> On 11.08.19 19:56, Marcus wrote:
>>>> Am 11.08.19 um 19:40 schrieb Peter Kovacs:
>>>>> I have adjusted the Function DetectRevisionId in
>>>>> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
>>>>> executed in a git repository.
>>>>>
>>>>> If it is not a git repository, it will fallback to the SVN logic.
>
> One addition:
>
> If it is a Git repository it should first look for a git-svn-id. Only
> if it isn't present it should use the git hash.
>
> This way it would be possible to build older revisions from Git with
> the SVN Revision (via git-svn-id).
> Only newer revisions (after the switch to Git) would use the git hash.
>
>>>>> The
>>>>> short hash includes a newline. I am not sure if that will make any
>>>>> trouble.
>
> Regarding the short git hash (vs. long git hash):
>
> I can live with it. But if there is something fundamentally wrong with
> using it (in our About dialog and on our download page) the Git gurus
> should speak up *now*. ;-)
>
> Regards,
>
> Matthias
>
>>>>> I have attached the patch. Please review. I could not test a complete
>>>>> build I have some building issues. (I will send some separated mails.)
>>>>>
>>>>> Also I have not checked in because of the lacking N2N test, and since I
>>>>> do not know what this newline does.
>>>> thanks for the piece of code. Any sideeffects need to be tested of
>>>> course.
>>>>
>>>> One problem I could image is the About dialog. Showing the Git hash
>>>> with a newline would be not suitable.
>>>>
>>>> Any other problem would be in the build system itself I thin.
>>>>
>>>> So, avoiding the newline would be great.
>>>>
>>>> Marcus
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <Pe...@Apache.org>.
Okay I am really out of practice with Perl.
I fixed an error in the script. I used the wrong command to escape to
the shell. -.-
please find an updated patch.
On 11.08.19 19:57, Peter Kovacs wrote:
> Ok. I remove it.
>
> On 11.08.19 19:56, Marcus wrote:
>> Am 11.08.19 um 19:40 schrieb Peter Kovacs:
>>> I have adjusted the Function DetectRevisionId in
>>> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
>>> executed in a git repository.
>>>
>>> If it is not a git repository, it will fallback to the SVN logic. The
>>> short hash includes a newline. I am not sure if that will make any
>>> trouble.
>>>
>>>
>>> I have attached the patch. Please review. I could not test a complete
>>> build I have some building issues. (I will send some separated mails.)
>>>
>>> Also I have not checked in because of the lacking N2N test, and since I
>>> do not know what this newline does.
>> thanks for the piece of code. Any sideeffects need to be tested of
>> course.
>>
>> One problem I could image is the About dialog. Showing the Git hash
>> with a newline would be not suitable.
>>
>> Any other problem would be in the build system itself I thin.
>>
>> So, avoiding the newline would be great.
>>
>> Marcus
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: get Revision from Git (short Hash)
Posted by Peter Kovacs <Pe...@Apache.org>.
Ok. I remove it.
On 11.08.19 19:56, Marcus wrote:
> Am 11.08.19 um 19:40 schrieb Peter Kovacs:
>> I have adjusted the Function DetectRevisionId in
>> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
>> executed in a git repository.
>>
>> If it is not a git repository, it will fallback to the SVN logic. The
>> short hash includes a newline. I am not sure if that will make any
>> trouble.
>>
>>
>> I have attached the patch. Please review. I could not test a complete
>> build I have some building issues. (I will send some separated mails.)
>>
>> Also I have not checked in because of the lacking N2N test, and since I
>> do not know what this newline does.
>
> thanks for the piece of code. Any sideeffects need to be tested of
> course.
>
> One problem I could image is the About dialog. Showing the Git hash
> with a newline would be not suitable.
>
> Any other problem would be in the build system itself I thin.
>
> So, avoiding the newline would be great.
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: get Revision from Git (short Hash)
Posted by Marcus <ma...@wtnet.de>.
Am 11.08.19 um 19:40 schrieb Peter Kovacs:
> I have adjusted the Function DetectRevisionId in
> main/solenv/bin/modules/SvnRevision.pm to return the short hash when
> executed in a git repository.
>
> If it is not a git repository, it will fallback to the SVN logic. The
> short hash includes a newline. I am not sure if that will make any trouble.
>
>
> I have attached the patch. Please review. I could not test a complete
> build I have some building issues. (I will send some separated mails.)
>
> Also I have not checked in because of the lacking N2N test, and since I
> do not know what this newline does.
thanks for the piece of code. Any sideeffects need to be tested of course.
One problem I could image is the About dialog. Showing the Git hash with
a newline would be not suitable.
Any other problem would be in the build system itself I thin.
So, avoiding the newline would be great.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org