[FFmpeg-devel] [RFC] What to do with 15k euro from STF?

[Diederick C. Niehorster]

On Tue, Nov 12, 2024 at 9:44 AM martin schitter <ms+git at mur.at> wrote:
>
>
>
> On 12.11.24 08:51, Martin Storsjö wrote:
> > On Tue, 12 Nov 2024, martin schitter wrote:
> >
> >> The git history of Patches here on this mailinglist are usually
> >> rewritten whenever one of the reviewers requests some change, but the
> >> typical workflow in github/gitlab doesn't use or even forbids this
> >> kind of changes in uploaded code resp. forced pushes. It's enforcing a
> >> strict incremental timeline of changes.
> >
> > This is entirely up to the policy of each individual project; it's
> > totally possible to use the exact same workflow with rewriting and force
> > pushing the PR/MR branch, with both github and gitlab. Gitlab is usually
> > a bit better at tracking review state across such events than github
> > though. Anyway, this is how all such reviews are conducted on e.g. the
> > videolan gitlab/projects.
>
> Well -- you can try to work around these limitations to some degree, but
> as a rule of thumb you should simply avoid git history rewrites and
> forced push's in MRs and any other form of published/shared remote
> branches in GitLab, although no strict protection mechanism will hinder
> you to use it in your own forks or any other unprotected branch, where
> you have sufficient access privileges, but the system simply doesn't
> like this kind of handling -- i.e. it will cause unwanted side effects:

Wouldn't the solution be for each new version of a patch to be a new
merge request, linked in the message to the previous MR (which is
closed when the new version is posted)?

Cheers,
Dee