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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 11, 2022, 16:58 UTC
Message-ID: <xmqqilrfk14q.fsf@gitster.g>
In-Reply-To: <CANgJU+Wr+tKNPfeh4dst-E_LSnoYYmN1easqmkFUA9spp-rpKQ@mail.gmail.com>

demerphq <demerphq@gmail.com> writes:

Show 21 quoted lines

> On Sat, 9 Apr 2022 at 02:43, Junio C Hamano <gitster@pobox.com> wrote:
>
>> > Giving "--since" the "as-filter" variant sets a precedent, and
>> > closes the door for a better UI that we can extend more generally
>> > without having to add "--X-as-filter" for each and every conceivable
>> > "--X" that is a traversal stopper into a filtering kind.
>>
>> If we pursue the possibility further, perhaps we may realize that
>> there isn't much room for us to add too many "traversal stoppers" in
>> the future, in which case giving "as-filter" to a very limited few
>> traversal stoppers may not be too bad.  I just do not think we have
>> explored that enough to decide that "--since-as-filter" is a good UI
>> (and it is not a good timing for me to spend brain cycles on the
>> issue).
>
> 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.

Thanks.