Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Thiago Macieira]

On Monday, 12 July 2021 14:22:54 PDT Elvis Stansvik wrote:
> Personally I'm always frustrated when I hit a dead end during git
> blame. Even if the original repo will be kept around, it's an added
> obstacle. And at some point, I'm sure it will no longer be available.

Yup, very often you do a git blame and you get to "Initial import from the 
monolithic Qt.", which is the beginning of the split repositories in Qt 5. You 
can do a git replace to stitch together with the qt.git history, but as you 
said it's an extra obstacle. Though in that case it's a valid reason, since we 
split the repositories instead of merging.

Then you do a git blame there and find it came from "Long live Qt 4.5!", the 
initial Git public history commit.

I also remember once when I was still at Nokia / Trolltech doing a git blame 
on the old history imported from Perforce and the line I was searching for, 
modulo a massive tab-removal commit, led back to the first check in of Qt into 
CVS.

https://github.com/qt/qt/blob/4.8/src/corelib/tools/qpoint.h#L96-L102

The macros changed; the whitespace got replaced, but the #else is from the 
very first Qt commit.

And this one is probably so too and is STILL there:
https://github.com/qt/qtbase/blob/dev/src/corelib/kernel/qobjectdefs.h#L60-L69

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Elvis Stansvik]

Den mån 12 juli 2021 kl 22:45 skrev Tor Arne Vestbø :
>
>
>
>
> On 12 Jul 2021, at 21:19, Thiago Macieira  wrote:
>
> So a full history import MAY have negligible marginal impact over a squashed
> import (.git is compressed). I recommend trying both and seeing by how much
> the qtdeclarative repository increases, then deciding whether "git blame" and
> "git log" working out of the box without a "git replace" is worth the extra
> cost.
>
>
> That’s a good point.

Concur.

Personally I'm always frustrated when I hit a dead end during git
blame. Even if the original repo will be kept around, it's an added
obstacle. And at some point, I'm sure it will no longer be available.

Just the other week I was trying to find the rationale for something
in a (non-Qt) project, and hit that kind of dead end. The code had
been moved in from another repo, without history, and the original
repo was not available anymore.

Elvis

>
> Cheers,
> Tor Arne
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

On 12 Jul 2021, at 21:19, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:

So a full history import MAY have negligible marginal impact over a squashed
import (.git is compressed). I recommend trying both and seeing by how much
the qtdeclarative repository increases, then deciding whether "git blame" and
"git log" working out of the box without a "git replace" is worth the extra
cost.

That’s a good point.

Cheers,
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Thiago Macieira]

On Monday, 12 July 2021 08:03:48 PDT Oswald Buddenhagen wrote:
> that would avoid duplicating the history, which would make the repo
> somewhat smaller and leave us with only one authoritative copy of said
> history (the original module will have to stay around for quite a while
> and keep receiving fixes anyway).

FYI, qtquickcontrols2 right now is (git count-objects -v):
size-pack: 34347

But that's almost equivalent to the checkout size:

$ du -sc * | tail -1 
34136   total

(* does not include .git)

So a full history import MAY have negligible marginal impact over a squashed 
import (.git is compressed). I recommend trying both and seeing by how much 
the qtdeclarative repository increases, then deciding whether "git blame" and 
"git log" working out of the box without a "git replace" is worth the extra 
cost.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

On 12 Jul 2021, at 17:03, Oswald Buddenhagen 
mailto:oswald.buddenha...@gmx.de>> wrote:

On Mon, Jul 12, 2021 at 02:17:01PM +, Tor Arne Vestbø wrote:
One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

it would be actually also just a subtree merge, but of a re-import, to which 
the old history would be grafted (that is, git-replaced when using up-to-date 
git mechanisms).
that would avoid duplicating the history, which would make the repo somewhat 
smaller and leave us with only one authoritative copy of said history (the 
original module will have to stay around for quite a while and keep receiving 
fixes anyway).

Ah, right, so a subtree merge of a “Import controls2” squashed commit that is 
then grafted to point to the old repo’s history if needed for log/bisects (or 
something along those line).

Can you help out with the concrete git steps that are needed for that since you 
have the flow mapped out better than me and Mitch?

Thanks!

Cheers,
Tor Arne



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Oswald Buddenhagen]

On Mon, Jul 12, 2021 at 02:17:01PM +, Tor Arne Vestbø wrote:

One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

it would be actually also just a subtree merge, but of a re-import, to 
which the old history would be grafted (that is, git-replaced when using 
up-to-date git mechanisms).
that would avoid duplicating the history, which would make the repo 
somewhat smaller and leave us with only one authoritative copy of said 
history (the original module will have to stay around for quite a while 
and keep receiving fixes anyway).


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Mitch Curtis]

Thanks Tor Arne. Can you elaborate a bit on the commands used for a prefixed 
subtree merge? Or point to a page that explains it?

From: Tor Arne Vestbø 
Sent: Monday, 12 July 2021 4:17 PM
To: Mitch Curtis 
Cc: development@qt-project.org
Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative

One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

Cheers,
Tor Arne


On 12 Jul 2021, at 14:42, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

“Graft history in, don't merge it.”

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Tor Arne Vestbø]

One way to do this is with a prefixed subtree merge without squashing the 
history of controls2.

What ossi (?) referred to was using git replace to inject the history of 
controls, but I’m not sure how that would look so perhaps he can outline that 
approach.

Cheers,
Tor Arne

On 12 Jul 2021, at 14:42, Mitch Curtis 
mailto:mitch.cur...@qt.io>> wrote:

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

“Graft history in, don't merge it.”

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Merging qtquickcontrols2 into qtdeclarative

[Mitch Curtis]

Hi.

The consensus from the contributor's summit session regarding 
https://bugreports.qt.io/browse/QTBUG-79454 was that qtquickcontrols2 should be 
merged into qtdeclarative:

https://wiki.qt.io/QtCS2021_-_Testing_upstream_changes_with_downstream_modules#Move_specific_modules_into_the_repository_of_the_module_they_depend_on

In terms of Git, what is the best way to proceed with this? Which commands 
should be used? Any specific things to be aware of? For example, one note made 
during the session was:

"Graft history in, don't merge it."

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Kaj Grönholm as approver

[Volker Hilsheimer]

Hi,


I’d like to nominate Kaj Grönholm as an approver for the Qt Project.

Kaj has been working primarily on Qt 3D Studio and Qt Quick 3D, most recently 
on the particle effects support in Qt 6.

He has authored the following patches:

https://codereview.qt-project.org/q/owner:kaj.gronholm%2540qt.io

and reviewed these:

https://codereview.qt-project.org/q/reviewer:kaj.gronholm%2540qt.io


Cheers,
Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ivan Solovev as approver

[Alex Blasche]

Congratulations to Ivan. Approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of Alex
> Blasche
> Sent: Tuesday, 15 June 2021 13:18
> To: development@qt-project.org
> Subject: [Development] Nominating Ivan Solovev as approver
> 
> Hi,
> 
> I'd like to nominate Ivan Solovev as an approver for the Qt Project.
> 
> Ivan has been working on various parts of the Qt6 port and has regularly
> contributed to QtBase  modules, QtPositioning, QtNfc & other modules.
> Personally, I am particularly thankful for his help in furthering the Qt 
> Bindings
> support in QtPositioning and his review of countless other patches in the same
> domain.
> 
> He has authored the following patches:
> https://codereview.qt-project.org/q/owner:ivan.solovev%2540qt.io,100
> and reviewed the following:
> https://codereview.qt-project.org/q/reviewer:ivan.solovev%2540qt.io,100
> 
> Since  both our office rooms share one wall I am also thankful for many
> technical discussions who broke the enforced solitude of the corona days :)
> 
> --
> Alex
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Aleksei German as aproover

[Alex Blasche]

Congratulations to Aleksei. Approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of
> Thomas Hartmann
> Sent: Monday, 14 June 2021 12:27
> To: development@qt-project.org
> Subject: [Development] Nominating Aleksei German as aproover
> 
> Hi all,
> 
> I'd like to nominate Aleksei German as an approver for the Qt Project.
> 
> Aleksei has been working on Qt Studio Design Studio and has regularly
> contributed to Qt Design Studio and Qt Creator.
> He implemented annotation support and improved the property editor and form
> editor. Aleksei is also taking care of the MCU support.
> 
> Qt Commits:
>https://codereview.qt-project.org/q/owner:aleksei.german%2540qt.io
> 
> Currently, Aleksei is working on a few last features for annotations and will
> continue with MCU support.
> Mandatory disclaimer: We work in the same team.
> 
> I trust him to be a good reviewer.
> 
> Best regards,
> Thomas Hartmann
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Knud Dollereder as approver

[Alex Blasche]

Congratulations to Knud. Approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of
> Thomas Hartmann
> Sent: Monday, 14 June 2021 12:21
> To: development@qt-project.org
> Subject: [Development] Nominating Knud Dollereder as approver
> 
> Hi all,
> 
> I'd like to nominate Knud Dollereder as an approver for the Qt Project.
> 
> Mahmoud has been working on Qt 3D Studio Design Studi and has regularly
> contributed to Qt Design Studio and Qt Creator.
> He helped with implementing the timeline and implemented the curve editor.
> 
> Qt Commits:
>https://codereview.qt-project.org/q/owner:knud.dollereder%2540qt.io
> 
> Currently, Knud is working on Qt 6 support and helps with macOS issues.
> Mandatory disclaimer: We work in the same team.
> 
> I trust him to be a good reviewer.
> 
> Best regards,
> Thomas Hartmann
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Henning Gründl as approver

[Alex Blasche]

Congratulations to Henning. Approver rights have been granted.

--
Alex

> -Original Message-
> From: Development  On Behalf Of
> Thomas Hartmann
> Sent: Monday, 14 June 2021 12:30
> To: development@qt-project.org
> Subject: [Development] Nominating Henning Gründl as approver
> 
> Hi all,
> 
> I'd like to nominate Henning Gründl as an approver for the Qt Project.
> 
> Henning has been working on Qt Studio Design Studio and has regularly
> contributed to Qt Design Studio and Qt Creator.
> He helped to integrate the advanced dock widget framework and did a lot of
> work on the property editor.
> 
> Qt Commits:
>https://codereview.qt-project.org/q/owner:henning.gruendl%2540qt.io
> 
> Currently, Henning is further improving the property editor.
> Mandatory disclaimer: We work in the same team.
> 
> I trust him to be a good reviewer.
> 
> Best regards,
> Thomas Hartmann
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development