Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Sze Howe Koh]

On Tue, 13 Jul 2021 at 21:38, Michal Klocek  wrote:
>
> Hi
>
> Please note qtpdf repository was merged into qtwebengine, authors wanted to 
> keep all the history so it was kept and git blame works nicely. However, 
> qtwebengine git repo is anyway big in size so adding extra ~100 commits did 
> not have much impact.
>
> https://codereview.qt-project.org/c/qt/qtwebengine/+/270649
>
> Br
>
> Michal
> 
> From: Development  on behalf of Elvis 
> Stansvik 
> Sent: Tuesday, 13 July 2021 13:23
> To: Qt development mailing list 
> Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative
>
> Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
> :
> >
> > >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).
> > >
> > that might be the case.
> >
> > but the point remains that the history that didn't exist along the
> > merged mainline would live elsewhere (unless we'd import all branches
> > and tags as well - we actually did that in qt creator, and it looks
> > kinda weird and confusing).
> >
> > On Mon, Jul 12, 2021 at 11:22:54PM +0200, 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.
> > >
> > a rather small obstacle, given that we have a git-qt-grafts script that
> > pretty much completely automates the process (it would actually need a
> > bit of a revamp by now).
>
> Yea, I just thought it a good idea to follow Thiago's suggestion to
> see what the cost would be to do a full history import. But I may have
> misunderstood what is even possible and not.
>
> As an outsider doing a sort of drive-by git blame trying to find the
> rationale for something, I may not know about special tooling that Qt
> has.
>
> But yes, you folks who work day to day on Qt should decide. Just
> wanted to chime in with my opinion.
>
> >
> > >And at some point, I'm sure it will no longer be available.
> > >
> > we keep around all repos. the remote may just need an adjustment to
> > point to {graveyard}/.
>
> Alright, that's good. In the project I was digging through the other
> week, the commit that added the code didn't even say where it came
> from, just something like "Code moved from old repo", and after
> extensive searching I concluded that "old repo" was no longer online.
>
> Qt being a more serious project, I'm sure you guys will leave a better
> commit message and won't start bulldozing over your {graveyard}/ :)
>
> Elvis
>
> >
> > (speaking of which, it might be actually time to do that with qt.git,
> > rather than only renaming it.)

I tried this on my local repo and there were surprisingly few
conflicts (most were in dist/changes-*).

cd qtdeclarative
git checkout dev
git remote add -f qqc2 ../qtquickcontrols2
git merge --allow-unrelated-histories qqc2/dev

If we prepare qtquickcontrols2.git beforehand (for example, by moving
dist/ into a subdirectory), the conflicts would be reduced. The
labour-intensive part is then merging the CMakeLists and testing.

If I understood the earlier talk about "grafting" correctly, it can
avoid the history duplication that occurs with my approach above.
However, I don't know how to achieve that -- Could someone kindly post
a sequence of commands?


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

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Thiago Macieira]

On Tuesday, 13 July 2021 01:43:58 PDT Oswald Buddenhagen wrote:
> but the point remains that the history that didn't exist along the
> merged mainline would live elsewhere (unless we'd import all branches
> and tags as well - we actually did that in qt creator, and it looks
> kinda weird and confusing).

Right, no branches or tags. Just the secondary history root.

-- 
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

[Michal Klocek]

Hi

Please note qtpdf repository was merged into qtwebengine, authors wanted to 
keep all the history so it was kept and git blame works nicely. However, 
qtwebengine git repo is anyway big in size so adding extra ~100 commits did not 
have much impact.

https://codereview.qt-project.org/c/qt/qtwebengine/+/270649

Br

Michal

From: Development  on behalf of Elvis 
Stansvik 
Sent: Tuesday, 13 July 2021 13:23
To: Qt development mailing list 
Subject: Re: [Development] Merging qtquickcontrols2 into qtdeclarative

Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
:
>
> >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).
> >
> that might be the case.
>
> but the point remains that the history that didn't exist along the
> merged mainline would live elsewhere (unless we'd import all branches
> and tags as well - we actually did that in qt creator, and it looks
> kinda weird and confusing).
>
> On Mon, Jul 12, 2021 at 11:22:54PM +0200, 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.
> >
> a rather small obstacle, given that we have a git-qt-grafts script that
> pretty much completely automates the process (it would actually need a
> bit of a revamp by now).

Yea, I just thought it a good idea to follow Thiago's suggestion to
see what the cost would be to do a full history import. But I may have
misunderstood what is even possible and not.

As an outsider doing a sort of drive-by git blame trying to find the
rationale for something, I may not know about special tooling that Qt
has.

But yes, you folks who work day to day on Qt should decide. Just
wanted to chime in with my opinion.

>
> >And at some point, I'm sure it will no longer be available.
> >
> we keep around all repos. the remote may just need an adjustment to
> point to {graveyard}/.

Alright, that's good. In the project I was digging through the other
week, the commit that added the code didn't even say where it came
from, just something like "Code moved from old repo", and after
extensive searching I concluded that "old repo" was no longer online.

Qt being a more serious project, I'm sure you guys will leave a better
commit message and won't start bulldozing over your {graveyard}/ :)

Elvis

>
> (speaking of which, it might be actually time to do that with qt.git,
> rather than only renaming it.)
> ___
> 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Merging qtquickcontrols2 into qtdeclarative

[Elvis Stansvik]

Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
:
>
> >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).
> >
> that might be the case.
>
> but the point remains that the history that didn't exist along the
> merged mainline would live elsewhere (unless we'd import all branches
> and tags as well - we actually did that in qt creator, and it looks
> kinda weird and confusing).
>
> On Mon, Jul 12, 2021 at 11:22:54PM +0200, 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.
> >
> a rather small obstacle, given that we have a git-qt-grafts script that
> pretty much completely automates the process (it would actually need a
> bit of a revamp by now).

Yea, I just thought it a good idea to follow Thiago's suggestion to
see what the cost would be to do a full history import. But I may have
misunderstood what is even possible and not.

As an outsider doing a sort of drive-by git blame trying to find the
rationale for something, I may not know about special tooling that Qt
has.

But yes, you folks who work day to day on Qt should decide. Just
wanted to chime in with my opinion.

>
> >And at some point, I'm sure it will no longer be available.
> >
> we keep around all repos. the remote may just need an adjustment to
> point to {graveyard}/.

Alright, that's good. In the project I was digging through the other
week, the commit that added the code didn't even say where it came
from, just something like "Code moved from old repo", and after
extensive searching I concluded that "old repo" was no longer online.

Qt being a more serious project, I'm sure you guys will leave a better
commit message and won't start bulldozing over your {graveyard}/ :)

Elvis

>
> (speaking of which, it might be actually time to do that with qt.git,
> rather than only renaming it.)
> ___
> 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 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).



that might be the case.

but the point remains that the history that didn't exist along the 
merged mainline would live elsewhere (unless we'd import all branches 
and tags as well - we actually did that in qt creator, and it looks 
kinda weird and confusing).


On Mon, Jul 12, 2021 at 11:22:54PM +0200, 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.

a rather small obstacle, given that we have a git-qt-grafts script that 
pretty much completely automates the process (it would actually need a 
bit of a revamp by now).



And at some point, I'm sure it will no longer be available.

we keep around all repos. the remote may just need an adjustment to 
point to {graveyard}/.


(speaking of which, it might be actually time to do that with qt.git, 
rather than only renaming it.)

___
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 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<mailto: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