On Tue, Nov 12, 2024 at 9:44 AM martin schitter <ms+...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
