Hi Junio

On 29/06/2026 17:54, Junio C Hamano wrote:

Phillip Wood [off-list ref] writes:

quoted

We should sanitize what the user passes though - we do not want to
accept arbitrary rev-list options. Off the top of my head "--left-only"
and "--right-only" would allow the use of "A...B" and allowing "--not"
seems reasonable.

I would not recommend guessing what these rev-list "expressions"
would produce and blacklist some of the operations and notations.
It would be a more robust approach to let the machinery do its thing
to determine the set of commits, *and* inspect the shape of the
history these commits represent.  Are they connected?  Do they have
a single "bottom" that is just outside and below the range so that
we can replace it with the result of squashing everything together?
Do they have a single "top" whose children can be rewritten to have
the resulting single commit as one of their parents?  Starting from
the acceptable shape of the history we want to deal with, rather
than trying to enumerate rev-list operations and notations that
would prevent the resulting set of commits to fall outside the
acceptable shape of the history (and I am reasonably sure anybody
who attempts to do so would either end up with unusablly narrow
subset of what we can reasonably handle, or miss some cases that we
do not want to handle), would be a better approach.

I think we still want some sanity checks similar to "git replay" though 
to ensure the user has not overridden "--reverse", "--topo-order", and 
"--boundary". It will be easier to sanity check the list of commits if 
we can at least rely on those options being set as we know what order to 
expect them in and can detect merge parents that are outside the range 
by looking for BOUNDARY commits.

Thanks

Phillip