On 12 Nov 2024, at 10:09, Diederick C. Niehorster wrote:
> 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)? IMO thats a terrible workflow as it looses context (but of course nothing prevents you from doing it). Like I said in my other reply, I have yet to see any big issues by force-pushing to MRs, we do it at VideoLAN for years already. > > 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". _______________________________________________ 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".
