Re: [log4cxx] next_stable and other fixes
Guten Tag Stephen Webb, am Dienstag, 4. Januar 2022 um 04:51 schrieben Sie: > Once the branches diverge, git cherry-pick is the better merge process. They have diverged already and all changes from master were decided to be useful in next_stable. So the results of cherry-picking and merging would be identical right now anyway. Additonally, diverging branches increase the risk of smaller cherry-picks to not apply cleanly as well. I don't see how this can be avoided besides saying to mostly NOT merge/cherry-pick at all and only do so exceptionally. But if the merged changes were useful in general for next_stable... Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: 05151- 9468- 0 Tel: 05151- 9468-55 Fax: 05151- 9468-88 Mobil: 0178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
Re: [log4cxx] next_stable and other fixes
Once the branches diverge, git cherry-pick is the better merge process. On Tue, Jan 4, 2022 at 11:06 AM Robert Middleton wrote: > Just as a note to all, what I've been doing with next_stable is to > periodically merge master back in once I make fixes on master(assuming > that those fixes are common to both). Unfortunately with the > multithreaded speed fix this has resulted in a moderately sized merge > conflict. I think I've fixed everything to work properly at this > point. > > What should our workflow be? Is there a better way? Obviously there > are certain things that would only target next_stable and not master, > so I'm not thinking about those cases for this. > > -Robert Middleton >
[log4cxx] next_stable and other fixes
Just as a note to all, what I've been doing with next_stable is to periodically merge master back in once I make fixes on master(assuming that those fixes are common to both). Unfortunately with the multithreaded speed fix this has resulted in a moderately sized merge conflict. I think I've fixed everything to work properly at this point. What should our workflow be? Is there a better way? Obviously there are certain things that would only target next_stable and not master, so I'm not thinking about those cases for this. -Robert Middleton