Git merge workflow: reverse it?

[Michael Reeves]

"You keep track of your patches (more or less
succesfully) and cherry-pick or port them."

This sums up what I do with kdiff3. In fact right now trying to merge
between stable and master or the other way around would be a nightmare
project due to heavy refactoring.

On Mon, Aug 24, 2020, 4:07 PM <boud at valdyas.org> wrote:

> On 2020-08-24 21:55, Albert Astals Cid wrote:
>
> > I disagree for it to per project, it has to be a global policy,
> > otherwise contributing gets more complicated, since I have to remember
> > for each project if they want bugfix patches to master or to stable.
>
> The current "global policy" isn't global already, of course. I'd never
> even heard of it. And if I had, I would never have accepted it, since
> it's bad practice. You don't merge stable branches into unstable, or the
> other way around. You keep track of your patches (more or less
> succesfully) and cherry-pick or port them.
>
> It's the maintainer's job to keep track of that, or make sure the other
> team members know what they should do.
>
> > Or at least it has to be the same for all the release service
> > projects, because otherwise it'll break my brain when doing the
> > branching for new releases. Right now i know that we always commit to
> > stable and then merge to master, but since people are lazy i know i
> > have to run a merge from stable to master before branch for all
> > projects, if we let this decision to be per project, what do I do?
>
> You don't do anything; if the maintainers of those projects cannot
> manage their patch workflow, well, shucks. And if you're the maintainer,
> then you need to keep track of all that.
>
> Boudewij
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20200824/71e30ddc/attachment.htm>