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

[martin schitter]

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:

see:
https://gitlab.com/gitlab-org/gitlab/-/issues/241509
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/31484
https://gitlab.com/gitlab-org/gitlab/-/issues/232630
https://docs.gitlab.com/ee/topics/git/git_rebase.html#force-push-to-a-remote-branch

This shift towards the commonly advised workflow of strict unmodified 
incremental change sets and final squash merges on this kind of 
platforms also affects the placement of patch related comments, 
otherwise they get silently lost at the end.

martin