Re: Incorrect merge

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> BTW, do you realize that the script would end cherry-picking commits
>
> Can't it instead do a merge and then reverse cherry-pick the revisions
> that should not be merged?

That's an option. It would be effective even for an human operator, as
the number of commits on emacs-23 not intented for trunk is so small
(that would not save the time required for reviewing the log messages
looking for some text flagging that condition, though)

IMO it is not a good thing to create revert commits as part of a
process. In this case, they will break bisecting and add potential
confussion to the VC history. For instance: the merged commits will be
hidden by default on level 1 of the DAG, but the reverting commits will
be always visible on the leftmost level of the DAG, unless you
complicate things by creating a branch containing the revert commits and
merge it into trunk.

It is desirable that patches not intended for trunk should never be on
trunk.