Re: git log --since to not stop after first old commit?

>> When you do have the cycles perhaps it is worth considering whether
>> splitting it up, so that --as-filter is a modifier for traversal stoppers,
>> would avoid the problem of proliferating options.   Eg, instead of saying
>> --since-as-filter you would say --since ... --as-filter. That way the
>> stoppers where "filter like behavior" made sense could just check if the
>> --as-filter flag was set.
>
> Yes, that has exactly the opposite problem I wanted to warn us about
> by sending an extra message (to which you are reponding to).  If we
> have (or can have) very many traversal stopping option, it might
> make sense to have --as-filter as a modifier and avoid doubling the
> number of options, but if we only have very few (and fundamentally
> cannot have more than very few), then giving each of these very few
> --X its own --X-as-filter variant would probably make more sense.
> Because end users would probably not know which ones are inherently
> filters and will not be affected with --as-filter modifier, it would
> help them understand if we give them independent --since-as-filter
> option and document it separately, if there aren't many of them.
>
> Besides, if we had very few but still multiple of them, --X and
> --Y-as-filter can be combined to say "X stops as before, but Y is
> applied as filter", which is strictly more expressive than a
> separate --as-filter modifier.
>
> So that is why I threw out the message for those interested in the
> topic to first think about.  I know we agree that --since may be a
> good candidate to have these two flavours of behaviour.  I do not
> think anybody carefully thought about existing options to see if
> there are many like --since that want two flavours, let alone
> possible options we have said in the past that we may want to have
> but not yet added.