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