Both strategies have their pros and cons I think.
Without merge up:
con: You have to create multiple pull requests to fix one issue --> more
work for both developer and reviewer and a bigger mess of PR's
pro: No merge conflicts resp. the developer can solve those himself
With merge up:
pro: Only one merge request per issue, bringing them all with one merge
into the upper branch
con: The person who does the merge may not know how to resolve the merge
conflicts
Am 09.11.22 um 15:56 schrieb Chris Morley:
As the dev that must approve the request, you can send a comment:
This looks like it needs to go in master too, "can you make another pull that
cherrypicks or commits this to master"
Or if you are so inclined you could take this on for your self.
So rather then you as the dev, having to figure out the merge conflicts of all
the conflicted code, the committer, who knows the code figures out the
conflicts only on his code.
Sent from my Galaxy
-------- Original message --------
From: andy pugh <bodge...@gmail.com>
Date: 2022-11-09 1:34 a.m. (GMT-08:00)
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] 2.9-pre1
On Wed, 9 Nov 2022 at 01:49, Chris Morley <chrisinnana...@hotmail.com>
wrote:
But it really doesn't make sense.
That is my point.
So, we get a pull-request for a bug fix in 2.8.
Who now decides whether it needs to be cherry-picked into 2.9 and 2.10? And
who does that?
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
