Git merge workflow: reverse it?

[Michael Reeves]

On Tue, May 10, 2022 at 10:48 AM Christoph Cullmann (cullmann.io) <
christoph at cullmann.io> wrote:

> On 2022-05-10 15:33, Nate Graham wrote:
> > On 5/10/22 04:15, Ingo Klöcker wrote:
> >>> https://manifesto.kde.org/commitments/
> >>
> >> I don't see anything in there that would force the same merge workflow
> >> on all
> >> KDE projects. In my view the merge workflow is comparable to the
> >> coding style.
> >>
> >> Regards,
> >> Ingo
> >
> > I don't think anyone is trying to force anything; rather, the proposal
> > is to get voluntary consensus around standardizing on a single
> > workflow (whatever it is) so that we all individually reap the
> > benefits of consistency by not having to remember two workflows, look
> > up which workflow a project uses, etc.
> >
> > Personally I don't care which one we standardize on, but I am in favor
> > of voluntarily and communally standardizing on one of them.
>
> Yeah, I doubt we can or want to force people.
>
> I personally prefer the cherry-pick approach from master
> to the stable branch(es), given I only work on the master branch and
> that is for me the best way to previously test the stuff properly.
>
> Naturally for e.g. Kate we only backport trivial stuff that way.
>

KDiff3 is in much the same position. In addition, stable branches are not
made on the rapid release schedule of KDE Applications. Meaning direct
merge either to or from master may produce unexpected results. Even cherry
picks sometimes need minor adjustment to work due to refactoring in master.


>
> Greetings
> Christoph
>
> >
> > Nate
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20220510/8171aaaa/attachment.htm>