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
_______________________________________________
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".
