Am 28.04.24 um 23:44 schrieb Kevin Kofler via devel:
Julian Sikorski wrote:
In this case defaulting to cherry-picking would be a safer bet. Branches
unintentionally separated can be merged, but branches unintentionally
merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the branches fast-forwarded (and using %{?fedora} conditionals
in the rare event something really needs to differ between the releases). A
linear history cannot be remade truly linear once it was diverged by a
cherry-pick (or simply a separate bump from running rpmdev-bumpspec
separately on each branch, as scripted rebuilds often do). The best we can
do to restore fast-forwardability is to merge one way and then "merge back",
which will fast-forward the other branch to the same merge commit. This
still leaves an ugly knot in the history, but at least the branches can then
be fast-forwarded again. But a clean linear history is no longer possible
after someone did an unwanted cherry pick instead of a fast-forward merge.
Kevin Kofler
Fair enough. Summing up, mass rebuilds are going to mess up whatever the
maintainer chose to do if the rebuilder decides to use the other approach.
Best regards,
Julian
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
