On 12 Nov 2024, at 9:44, martin schitter 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: > > 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. > Force pushing is a common way to update merge requests and I did not observe much issues at all with that workflow at VideoLAN where we do that for years already or elsewhere tbh. Sure the status change in the MR is not ideally reflected in all cases but you anyway have to re-review a MR when its code changes, so it is not much different to having to have a look again to when someone sends a v2 or a patchset. (The commits listed in the commit list will always reflect the accurate MR contents.) The documentation states „Force pushing is not recommended on shared branches, because you risk destroying others’ changes.“ emphasis here on „shared branches“, which of course makes sense as when you work on branches together, force pushing can be annoying and accidentally cause lost work if you aren’t careful and don’t use `--force-with-lease`, but generally a MR is authored by a single user (although not necessarily). > martin > _______________________________________________ > 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".
