On Wed, Jan 23, 2019 at 06:36:43PM +, Alex Blasche wrote:
> At the end of the day each cherry-pick is a merge too and they can
> conflict too. The conflict resolution process is still the same. if
> everything is conflict free then a git merge would be no more
> difficult than a cherry-pick.
On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
> 23.01.2019, 21:38, "Alex Blasche" :
> >>
> >> From: Martin Smith
> >> If you make all patches in dev and then cherrypick them back to earlier
> >> versions that need them, why would you
On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> Proposal in short: let's use cherry-pick mode everywhere.
>
> All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch
> cherry-
pick,
On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
> Jedrzej Nowacki wrote:
> >> Advantages:
> >> - no waiting for merges, a fix can be used right away after
> >>
> >>integration
> >>
> >> - faster propagation of fixes targeting all branches, as there are
> >>
> >>
On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
>> I think that’s fine. What’s much worse is having a fix in 5.12 and not
>> knowing how to deal with the merge conflicts into dev. That means dev might
>> regress, unless whoever authored the change is willing to spend time on
>>
Jedrzej Nowacki wrote:
>> Advantages:
>> - no waiting for merges, a fix can be used right away after
>>integration
>> - faster propagation of fixes targeting all branches, as there are
>>no merges of merges
Alex Blasche (23 January 2019 18:09)
> This is pure speculation because you
On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
> I think that’s fine. What’s much worse is having a fix in 5.12 and not
> knowing how to deal with the merge conflicts into dev. That means dev might
> regress, unless whoever authored the change is willing to spend time on
>
> On 23 Jan 2019, at 18:09, Alex Blasche wrote:
>
>
>>
>> From: Development on behalf of Jedrzej
>> Nowacki
>> Advantages:
>> - no waiting for merges, a fix can be used right away after integration
>> - faster propagation of fixes targeting all
: [Development] Proposal: New branch model
23.01.2019, 21:38, "Alex Blasche" :
>>
>> From: Martin Smith
>> If you make all patches in dev and then cherrypick them back to earlier
>> versions that need them, why would you ever do
23.01.2019, 21:38, "Alex Blasche" :
>>
>> From: Martin Smith
>> If you make all patches in dev and then cherrypick them back to earlier
>> versions that need them, why would you ever do a merge?
>
> At the end of the day each cherry-pick is a merge too
>
>From: Martin Smith
>If you make all patches in dev and then cherrypick them back to earlier
>versions that need them, why would you ever do a merge?
At the end of the day each cherry-pick is a merge too and they can conflict
too. The conflict
On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote:
> > Disadvantages:
> > - git history would be a bit wilder, "git branch --contains" would not
> > work
> > - commit messages in some branches would have kind of ugly footer as an
> >
> > effect of "cherry-pick -x"
>
>
>
>From: Development on behalf of Jedrzej
>Nowacki
> Advantages:
> - no waiting for merges, a fix can be used right away after integration
> - faster propagation of fixes targeting all branches, as there are no merges
of merges
This is pure
On 23 Jan 2019, at 17:20, Mitch Curtis
mailto:mitch.cur...@qt.io>> wrote:
[…snip…]
Advantages:
- no waiting for merges, a fix can be used right away after integration
Sounds nice!
- faster propagation of fixes targeting all branches, as there are no merges
of merges
- simpler for new
On 23 Jan 2019, at 17:08, Jaroslaw Kobus
mailto:jaroslaw.ko...@qt.io>> wrote:
"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We
> -Original Message-
> From: Development On Behalf Of
> Jedrzej Nowacki
> Sent: Wednesday, 23 January 2019 4:51 PM
> To: development@qt-project.org
> Subject: [Development] Proposal: New branch model
>
> Hi,
>
> It is time to rethink our branch model. We are approaching Qt6
>
"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"
No sure I
101 - 117 of 117 matches
Mail list logo
