From: Junio C Hamano <gitster@pobox.com>
To: Miklos Vajna <vmiklos@vmiklos.hu>, demerphq <demerphq@gmail.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: git log --since to not stop after first old commit?
Date: Fri, 22 Apr 2022 11:48:45 -0700 [thread overview]
Message-ID: <xmqqzgkd7y42.fsf@gitster.g> (raw)
In-Reply-To: <xmqqilrfk14q.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 11 Apr 2022 09:58:45 -0700")
Junio C Hamano <gitster@pobox.com> writes:
>> 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.
Now I had some time to think about it, I have a feeling that it is
quite unlikely for us to add traversal stopper other than since, so
having a separate "--as-filter" would probably be more confusing
than adding "--since-as-filter", stressing on "only the 'show
commits with timestamp after this one' has two variants".
Thanks.
next prev parent reply other threads:[~2022-04-22 19:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 8:21 git log --since to not stop after first old commit? Miklos Vajna
2022-04-01 9:57 ` Ævar Arnfjörð Bjarmason
2022-04-01 10:14 ` Miklos Vajna
2022-04-01 13:51 ` Ævar Arnfjörð Bjarmason
2022-04-01 17:51 ` Junio C Hamano
2022-04-01 21:36 ` [PATCH] git-log: add a --since-as-filter option Miklos Vajna
2022-04-02 10:09 ` [PATCH v2] " Miklos Vajna
2022-04-07 15:43 ` git log --since to not stop after first old commit? Miklos Vajna
2022-04-08 2:30 ` Junio C Hamano
2022-04-08 18:19 ` Junio C Hamano
[not found] ` <CANgJU+Wr+tKNPfeh4dst-E_LSnoYYmN1easqmkFUA9spp-rpKQ@mail.gmail.com>
2022-04-11 6:37 ` Miklos Vajna
2022-04-11 9:18 ` demerphq
2022-04-11 16:58 ` Junio C Hamano
2022-04-22 18:48 ` Junio C Hamano [this message]
2022-04-22 20:01 ` [PATCH v6] log: "--since-as-filter" option is a non-terminating "--since" variant Miklos Vajna
2022-04-22 22:11 ` Junio C Hamano
2022-04-22 23:43 ` Junio C Hamano
2022-04-23 12:59 ` [PATCH v7] " Miklos Vajna
2022-04-08 21:01 ` [PATCH v3] git-log: add a --since=... --as-filter option Miklos Vajna
2022-04-12 8:47 ` Ævar Arnfjörð Bjarmason
2022-04-15 20:39 ` [PATCH v4] " Miklos Vajna
2022-04-15 23:13 ` Junio C Hamano
2022-04-16 14:23 ` [PATCH v5] log: "--as-filter" option adjusts how "--since" cut-off works Miklos Vajna
2022-04-22 6:50 ` Miklos Vajna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzgkd7y42.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=demerphq@gmail.com \
--cc=git@vger.kernel.org \
--cc=vmiklos@vmiklos.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.