Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> This mini series makes it so that --no-merges undoes --merges
> and vice versa, as the user should be able to expect,
> and that --merges-only is a separate option.
Nice to see the series marked as RFD, but it would have been much better
what aspect of the series you wanted to be discussed.
I know that you have been here long enough to know that an outright
breakage of backward compatibility does not deserve a discussion, and that
you are feeling to see if people consider it is worth to design and
implement a migration path that is not fully specified by this series to
eventually give us the end result that is hinted by this series.
But I suspect some other readers on the list don't (and that is why I am
spelling it out).
As to the eventual goal, I think two modes "show me only merge commits",
"show me only commits that are not merges" are absolute nesessity no
matter how they are named, and as a uniformity bonus, "earlier I might
have said 'show me only merges' but I take it back" and its counterpart
might be good things to have.
But.
If a script writer wants to futureproof his script against later
introduction of configuration variables to trigger 'no-merges' and/or
'merges-only', what should she say? "git log --no-merges-only --merges"?
Shouldn't the choice offered by the eventual end result of this topic,
perhaps two years down the road after migration period, not two seemingly
independent options as hinted with the series, but an enum with three
values (any commit, non-merge commit only, merge commit only)?
IOW, wouldn't it be a more logical thing to do to add a new option with
three values --show-commit={all,merges,no-merges}, if we were adding the
feature to filter commits by number of parents?
If we come up with a nicer name for the --show-commit example above (both
the name of the variable and the enum value) and promote it, the migration
would go smoothly without giving much pain to the existing users and
scripts, as it will not _have to_ involve touching the existing merges and
no-merges options at all, even though we can make them less visible.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html