{"thread":{"id":"57647","subject":"git log --since to not stop after first old commit?","startedAt":"2022-04-01T08:21:53Z","lastAt":"2022-04-23T13:00:10Z","messageCount":24,"participants":["Miklos Vajna","Ævar Arnfjörð Bjarmason","Junio C Hamano","demerphq"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"452854","messageId":"Yka2GSGs3EIXm6Xt@vmiklos.hu","threadId":"57647","inReplyTo":null,"subject":"git log --since to not stop after first old commit?","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-01T08:21:45Z","receivedAt":"2022-04-01T08:21:53Z","isPatch":false,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"Hi,\n\nI wanted to look at commits of a contributor from the last year, and\nnoticed that I only see commits from this year, not last year when I use:\n\n git log --author=\"that person\" --since=\"1 year ago\"\n\nDigging around in the history, one other contributor pushed a mistake on\n1st Jan, where the author date was supposed to be 2022-01-01, but\nhappened to be 2021-01-01. Knowing that, it makes sense that 'git log'\nstopped at that commit by default.\n\nI wonder though, is there any option to \"force\" git log to walk all\nreachable commits from HEAD, but just show the ones which match the\n--since criteria?\n\nOr is this need so special that the best is to parse the output of 'git\nrev-list' and do my own filtering for author and date?\n\nThanks,\n\nMiklos\n"},{"id":"452858","messageId":"220401.86pmm1nmvh.gmgdl@evledraar.gmail.com","threadId":"57647","inReplyTo":"Yka2GSGs3EIXm6Xt@vmiklos.hu","subject":"Re: git log --since to not stop after first old commit?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-01T09:57:33Z","receivedAt":"2022-04-01T10:01:28Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 01 2022, Miklos Vajna wrote:\n\n> Hi,\n>\n> I wanted to look at commits of a contributor from the last year, and\n> noticed that I only see commits from this year, not last year when I use:\n>\n> git log --author=\"that person\" --since=\"1 year ago\"\n>\n> Digging around in the history, one other contributor pushed a mistake on\n> 1st Jan, where the author date was supposed to be 2022-01-01, but\n> happened to be 2021-01-01. Knowing that, it makes sense that 'git log'\n> stopped at that commit by default.\n\nSo (just making sure I understand this) in this case the --since option\nis behaving as expected in the sense that the information in the commit\nitself matches what it's finding, but what you'd really like for it to\nconsider some \"adjusted\" commit date?\n\nI.e. to be smart enough to spot that it should include a commit from\n2021 if all the preceding commits are from 2022, or some other similar\nheuristic?\n\nOr...\n\n> I wonder though, is there any option to \"force\" git log to walk all\n> reachable commits from HEAD, but just show the ones which match the\n> --since criteria?\n\n...did we stop the walk as soon as we saw that 2021 commit?\n\n> Or is this need so special that the best is to parse the output of 'git\n> rev-list' and do my own filtering for author and date?\n\nI think this is somewhere between \"we could grow a new feature to be\nmore helpful\" (we adjust commit dates in other places, i.e. commit-graph\nreachability), or \"a bug\" depending on the answersto the above, but I\nobviously haven't dug much. Hope this helps!\n"},{"id":"452859","messageId":"YkbQnnB8GSzuAROh@vmiklos.hu","threadId":"57647","inReplyTo":"220401.86pmm1nmvh.gmgdl@evledraar.gmail.com","subject":"Re: git log --since to not stop after first old commit?","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-01T10:14:54Z","receivedAt":"2022-04-01T10:15:03Z","isPatch":false,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"Hi Ævar,\n\nOn Fri, Apr 01, 2022 at 11:57:33AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> So (just making sure I understand this) in this case the --since option\n> is behaving as expected in the sense that the information in the commit\n> itself matches what it's finding, but what you'd really like for it to\n> consider some \"adjusted\" commit date?\n> \n> I.e. to be smart enough to spot that it should include a commit from\n> 2021 if all the preceding commits are from 2022, or some other similar\n> heuristic?\n\nNo heuristics. Just a way to not stop at the first commit that doesn't\nmatch the --since criteria. Here is an example:\n\nGiven:\n\nrm -rf .git file\ngit init\necho a > file\ngit add file\ngit commit -m init\necho a >> file\ngit add file\nGIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second\necho a >> file\ngit add file\ngit commit -m third\n\nWhen I do:\n\ngit log --pretty=oneline --since=\"2022-01-01\"\n\nThen current I get:\n\n91a24b6ccba6b1d26c3bd5bcea7ff86e6997b599 (HEAD -> master) third\n\nAnd I would like to have an opt-in way to instead get:\n\n91a24b6ccba6b1d26c3bd5bcea7ff86e6997b599 (HEAD -> master) third\ne259a40784d3d70f3878105adac380c8e8a8ae52 init\n\nArguing that both \"init\" and \"third\" was committed this year.\n\nThe question is if there is a way to do this already (perhaps I missed\nsomething in the docs or didn't notice it while I briefly researched the\ncommit walk code), or in case I want to do this, then would it make\nsense to have this feature in git or this is more a \"run git rev-list\nand do your own filtering\" case?\n\nThanks,\n\nMiklos\n"},{"id":"452868","messageId":"220401.86czi0oqfl.gmgdl@evledraar.gmail.com","threadId":"57647","inReplyTo":"YkbQnnB8GSzuAROh@vmiklos.hu","subject":"Re: git log --since to not stop after first old commit?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-01T13:51:38Z","receivedAt":"2022-04-01T13:59:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 01 2022, Miklos Vajna wrote:\n\n> Hi Ævar,\n>\n> On Fri, Apr 01, 2022 at 11:57:33AM +0200, Ævar Arnfjörð Bjarmason wrote:\n>> So (just making sure I understand this) in this case the --since option\n>> is behaving as expected in the sense that the information in the commit\n>> itself matches what it's finding, but what you'd really like for it to\n>> consider some \"adjusted\" commit date?\n>> \n>> I.e. to be smart enough to spot that it should include a commit from\n>> 2021 if all the preceding commits are from 2022, or some other similar\n>> heuristic?\n>\n> No heuristics. Just a way to not stop at the first commit that doesn't\n> match the --since criteria. Here is an example:\n>\n> Given:\n>\n> rm -rf .git file\n> git init\n> echo a > file\n> git add file\n> git commit -m init\n> echo a >> file\n> git add file\n> GIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second\n> echo a >> file\n> git add file\n> git commit -m third\n>\n> When I do:\n>\n> git log --pretty=oneline --since=\"2022-01-01\"\n>\n> Then current I get:\n>\n> 91a24b6ccba6b1d26c3bd5bcea7ff86e6997b599 (HEAD -> master) third\n>\n> And I would like to have an opt-in way to instead get:\n>\n> 91a24b6ccba6b1d26c3bd5bcea7ff86e6997b599 (HEAD -> master) third\n> e259a40784d3d70f3878105adac380c8e8a8ae52 init\n>\n> Arguing that both \"init\" and \"third\" was committed this year.\n\nIndeed.\n\n> The question is if there is a way to do this already (perhaps I missed\n> something in the docs or didn't notice it while I briefly researched the\n> commit walk code), or in case I want to do this, then would it make\n> sense to have this feature in git or this is more a \"run git rev-list\n> and do your own filtering\" case?\n\nI think it might make sense to have it as feature, but hopefully we\ncould piggy-back on the date adjustment that the commit-graph needs to\ndo already, I'm not sure if we save that information anywhere though...\n\nThe assumption with --since was that this sort of timestamp drift\nwouldn't be this bad, so mostly it works out. It could be made to work\nlike --grep, but then it needs to walk the whole history if no other\nlimit is provided.\n\nSo it'll be very slow if you just want --since=2.weeks.ago, but\naccurate.\n\nI think an alternate solution to this in the meantime is to use \"git\nreplace\" as a band-aid, I haven't tried, but you should be able to\nreplace the relevant commit with one that has adjusted dates.\n"},{"id":"452913","messageId":"xmqq1qygy9nd.fsf@gitster.g","threadId":"57647","inReplyTo":"Yka2GSGs3EIXm6Xt@vmiklos.hu","subject":"Re: git log --since to not stop after first old commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-01T17:51:34Z","receivedAt":"2022-04-01T17:51:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna writes:\n\n> I wanted to look at commits of a contributor from the last year, and\n> noticed that I only see commits from this year, not last year when I use:\n>\n> git log --author=\"that person\" --since=\"1 year ago\"\n>\n> Digging around in the history, one other contributor pushed a mistake on\n> 1st Jan, where the author date was supposed to be 2022-01-01, but\n> happened to be 2021-01-01. Knowing that, it makes sense that 'git log'\n> stopped at that commit by default.\n>\n> I wonder though, is there any option to \"force\" git log to walk all\n> reachable commits from HEAD, but just show the ones which match the\n> --since criteria?\n>\n> Or is this need so special that the best is to parse the output of 'git\n> rev-list' and do my own filtering for author and date?\n\nCurrently yes. I am not sure if it is (or is not) worth changing,\nthough.\n\nMany \"git log\" options make commits hidden from the output by\nfiltering each commit we find but keep digging the history further,\nbut some options make commits hidden by stopping the traversal.\n\"--until\" is the former (there is no way to implement it as the\nlatter) but \"--since\" is the latter.\n\nIf we can implement more of these \"commit hiding operations\" as\ntraversal stoppers, it allows \"log\" to avoid doing unnecessary work,\nand in a history without skewed timestamps, \"--since\" is a prime\ncandidate to take advantage of the fact that parent must be older\nthan any of its children (hence we can safely stop traversal once we\nsee an old enough commit) to be implemented as a \"traversal stopper\".\nBut in the presense of skewed timestamps, those commits behind one\ncommit with an incorrectly old timestamp will end up being hidden.\n\nWe could add a --since-as-filter= option or something, but then the\nuser needs to be careful when to stop (and digging down to the root\nof the history, i.e. \"never stop\", may be an acceptable answer to\nsome projects). We may be able to, when commit-graph (v2) with\nadjusted timestamp data exist, stop before going down to the root,\nbut we would still need to add it as a different option because the\nexisting behaviour of \"--since\", to immediately stop upon seeing a\ncommit with a timestamp that is older than the given time, is so\nwell established and it would irritate users of existing scripts if\nit changes all of a sudden.\n\n\n"},{"id":"452922","messageId":"YkdwbUqM45T06R00@vmiklos.hu","threadId":"57647","inReplyTo":"xmqq1qygy9nd.fsf@gitster.g","subject":"[PATCH] git-log: add a --since-as-filter option","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-01T21:36:45Z","receivedAt":"2022-04-01T21:36:54Z","isPatch":true,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"This is similar to --since, but it will filter out not matching commits,\nrather than stopping at the first not matching commit.\n\nThis is useful if you e.g. want to list the commits from the last year,\nbut one odd commit has a bad commit date and that would hide lots of\nearlier commits in that range.\n\nThe behavior of --since is left unchanged, since it's valid to depend on\nits current behavior.\n---\n\nHi,\n\nOn Fri, Apr 01, 2022 at 10:51:34AM -0700, Junio C Hamano wrote:\n> We could add a --since-as-filter= option or something, but then the\n> user needs to be careful when to stop (and digging down to the root\n> of the history, i.e. \"never stop\", may be an acceptable answer to\n> some projects).\n\nHere is a patch that does this. As a somewhat arbitrary testcase, the\nLibreOffice core.git repo has 474064 commits and --since-as-filter\nfinishes in 688 ms for a sample query (and expected output), while I got\nempty output with --since previously. I would argue this is an\nacceptable trade-off.\n\nWhat do you think?\n\nThanks,\n\nMiklos\n\n Documentation/rev-list-options.txt | 5 +++++\n revision.c | 10 ++++++++++\n revision.h | 1 +\n t/t4217-log-limit.sh | 32 ++++++++++++++++++++++++++++++\n 4 files changed, 48 insertions(+)\n create mode 100755 t/t4217-log-limit.sh\n\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex fd4f4e26c9..ba01b1ba06 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -25,6 +25,11 @@ ordering and formatting options, such as `--reverse`.\n --after=::\n \tShow commits more recent than a specific date.\n \n+--since-as-filter=::\n+\tShow all commits more recent than a specific date. This visits all\n+\tcommits in the range, rather than stopping at the first commit which is older\n+\tthan a specific date.\n+\n --until=::\n --before=::\n \tShow commits older than a specific date.\ndiff --git a/revision.c b/revision.c\nindex 2646b78990..ebc95319d6 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1440,6 +1440,9 @@ static int limit_list(struct rev_info *revs)\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age) &&\n \t\t !revs->line_level_traverse)\n \t\t\tcontinue;\n+\t\tif (revs->max_age_as_filter != -1 && (commit->date < revs->max_age_as_filter) &&\n+\t\t !revs->line_level_traverse)\n+\t\t\tcontinue;\n \t\tdate = commit->date;\n \t\tp = &commit_list_insert(commit, p)->next;\n \n@@ -1838,6 +1841,7 @@ void repo_init_revisions(struct repository *r,\n \trevs->dense = 1;\n \trevs->prefix = prefix;\n \trevs->max_age = -1;\n+\trevs->max_age_as_filter = -1;\n \trevs->min_age = -1;\n \trevs->skip_count = -1;\n \trevs->max_count = -1;\n@@ -2218,6 +2222,9 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if ((argcount = parse_long_opt(\"since\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n+\t} else if ((argcount = parse_long_opt(\"since-as-filter\", argv, &optarg))) {\n+\t\trevs->max_age_as_filter = approxidate(optarg);\n+\t\treturn argcount;\n \t} else if ((argcount = parse_long_opt(\"after\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n@@ -3862,6 +3869,9 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n \tif (revs->min_age != -1 &&\n \t comparison_date(revs, commit) > revs->min_age)\n \t\t\treturn commit_ignore;\n+\tif (revs->max_age_as_filter != -1 &&\n+\t comparison_date(revs, commit) < revs->max_age_as_filter)\n+\t\t\treturn commit_ignore;\n \tif (revs->min_parents || (revs->max_parents >= 0)) {\n \t\tint n = commit_list_count(commit->parents);\n \t\tif ((n < revs->min_parents) ||\ndiff --git a/revision.h b/revision.h\nindex 5bc59c7bfe..e80c148b19 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -263,6 +263,7 @@ struct rev_info {\n \tint skip_count;\n \tint max_count;\n \ttimestamp_t max_age;\n+\ttimestamp_t max_age_as_filter;\n \ttimestamp_t min_age;\n \tint min_parents;\n \tint max_parents;\ndiff --git a/t/t4217-log-limit.sh b/t/t4217-log-limit.sh\nnew file mode 100755\nindex 0000000000..5b7d30d5ad\n--- /dev/null\n+++ b/t/t4217-log-limit.sh\n@@ -0,0 +1,32 @@\n+#!/bin/sh\n+\n+test_description='git log with filter options limiting the output'\n+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n+\n+. ./test-lib.sh\n+\n+GIT_TEST_COMMIT_GRAPH=0\n+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n+\n+test_expect_success 'setup test' '\n+\tgit init &&\n+\techo a > file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-02-01 0:00\" git commit -m init &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-03-01 0:00\" git commit -m third\n+'\n+\n+test_expect_success 'git log --since-as-filter' '\n+\tgit log --since-as-filter=\"2022-01-01\" --pretty=\"format:%s\" > actual &&\n+\ttest_i18ngrep init actual &&\n+\t! test_i18ngrep second actual &&\n+\ttest_i18ngrep third actual\n+'\n+\n+test_done\n-- \n2.34.1\n\n"},{"id":"452926","messageId":"Ykggy4poryul8uyG@vmiklos.hu","threadId":"57647","inReplyTo":"YkdwbUqM45T06R00@vmiklos.hu","subject":"[PATCH v2] git-log: add a --since-as-filter option","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-02T10:09:15Z","receivedAt":"2022-04-02T10:09:29Z","isPatch":true,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"This is similar to --since, but it will filter out not matching commits,\nrather than stopping at the first not matching commit.\n\nThis is useful if you e.g. want to list the commits from the last year,\nbut one odd commit has a bad commit date and that would hide lots of\nearlier commits in that range.\n\nThe behavior of --since is left unchanged, since it's valid to depend on\nits current behavior.\n\nSigned-off-by: Miklos Vajna \n---\n\nHi,\n\nOn Fri, Apr 01, 2022 at 11:36:48PM +0200, Miklos Vajna wrote:\n> Here is a patch that does this.\n\nOops, forgot the sign-off, fixed now.\n\nRegards,\n\nMiklos\n\n Documentation/rev-list-options.txt | 5 +++++\n revision.c | 10 ++++++++++\n revision.h | 1 +\n t/t4217-log-limit.sh | 32 ++++++++++++++++++++++++++++++\n 4 files changed, 48 insertions(+)\n create mode 100755 t/t4217-log-limit.sh\n\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex fd4f4e26c9..ba01b1ba06 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -25,6 +25,11 @@ ordering and formatting options, such as `--reverse`.\n --after=::\n \tShow commits more recent than a specific date.\n \n+--since-as-filter=::\n+\tShow all commits more recent than a specific date. This visits all\n+\tcommits in the range, rather than stopping at the first commit which is older\n+\tthan a specific date.\n+\n --until=::\n --before=::\n \tShow commits older than a specific date.\ndiff --git a/revision.c b/revision.c\nindex 2646b78990..ebc95319d6 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1440,6 +1440,9 @@ static int limit_list(struct rev_info *revs)\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age) &&\n \t\t !revs->line_level_traverse)\n \t\t\tcontinue;\n+\t\tif (revs->max_age_as_filter != -1 && (commit->date < revs->max_age_as_filter) &&\n+\t\t !revs->line_level_traverse)\n+\t\t\tcontinue;\n \t\tdate = commit->date;\n \t\tp = &commit_list_insert(commit, p)->next;\n \n@@ -1838,6 +1841,7 @@ void repo_init_revisions(struct repository *r,\n \trevs->dense = 1;\n \trevs->prefix = prefix;\n \trevs->max_age = -1;\n+\trevs->max_age_as_filter = -1;\n \trevs->min_age = -1;\n \trevs->skip_count = -1;\n \trevs->max_count = -1;\n@@ -2218,6 +2222,9 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if ((argcount = parse_long_opt(\"since\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n+\t} else if ((argcount = parse_long_opt(\"since-as-filter\", argv, &optarg))) {\n+\t\trevs->max_age_as_filter = approxidate(optarg);\n+\t\treturn argcount;\n \t} else if ((argcount = parse_long_opt(\"after\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n@@ -3862,6 +3869,9 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n \tif (revs->min_age != -1 &&\n \t comparison_date(revs, commit) > revs->min_age)\n \t\t\treturn commit_ignore;\n+\tif (revs->max_age_as_filter != -1 &&\n+\t comparison_date(revs, commit) < revs->max_age_as_filter)\n+\t\t\treturn commit_ignore;\n \tif (revs->min_parents || (revs->max_parents >= 0)) {\n \t\tint n = commit_list_count(commit->parents);\n \t\tif ((n < revs->min_parents) ||\ndiff --git a/revision.h b/revision.h\nindex 5bc59c7bfe..e80c148b19 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -263,6 +263,7 @@ struct rev_info {\n \tint skip_count;\n \tint max_count;\n \ttimestamp_t max_age;\n+\ttimestamp_t max_age_as_filter;\n \ttimestamp_t min_age;\n \tint min_parents;\n \tint max_parents;\ndiff --git a/t/t4217-log-limit.sh b/t/t4217-log-limit.sh\nnew file mode 100755\nindex 0000000000..5b7d30d5ad\n--- /dev/null\n+++ b/t/t4217-log-limit.sh\n@@ -0,0 +1,32 @@\n+#!/bin/sh\n+\n+test_description='git log with filter options limiting the output'\n+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n+\n+. ./test-lib.sh\n+\n+GIT_TEST_COMMIT_GRAPH=0\n+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n+\n+test_expect_success 'setup test' '\n+\tgit init &&\n+\techo a > file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-02-01 0:00\" git commit -m init &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-03-01 0:00\" git commit -m third\n+'\n+\n+test_expect_success 'git log --since-as-filter' '\n+\tgit log --since-as-filter=\"2022-01-01\" --pretty=\"format:%s\" > actual &&\n+\ttest_i18ngrep init actual &&\n+\t! test_i18ngrep second actual &&\n+\ttest_i18ngrep third actual\n+'\n+\n+test_done\n-- \n2.34.1\n\n"},{"id":"453268","messageId":"Yk8Gvf/fjVca9hDB@vmiklos.hu","threadId":"57647","inReplyTo":"xmqq1qygy9nd.fsf@gitster.g","subject":"Re: git log --since to not stop after first old commit?","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-07T15:43:57Z","receivedAt":"2022-04-07T15:44:25Z","isPatch":false,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"Hi Junio,\n\nOn Fri, Apr 01, 2022 at 10:51:34AM -0700, Junio C Hamano wrote:\n> We could add a --since-as-filter= option or something, but then the\n> user needs to be careful when to stop (and digging down to the root\n> of the history, i.e. \"never stop\", may be an acceptable answer to\n> some projects).\n\nI sent a patch to add such an option (which picks the \"never stop\"\nbehavior) on 1st, did you see that?\n\nIf the idea is OK in principle, but the patch needs tweaking, please let\nme know.\n\nThanks,\n\nMiklos\n"},{"id":"453308","messageId":"xmqqv8vkpara.fsf@gitster.g","threadId":"57647","inReplyTo":"Yk8Gvf/fjVca9hDB@vmiklos.hu","subject":"Re: git log --since to not stop after first old commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-08T02:30:33Z","receivedAt":"2022-04-08T02:30:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna writes:\n\n> On Fri, Apr 01, 2022 at 10:51:34AM -0700, Junio C Hamano wrote:\n>> We could add a --since-as-filter= option or something, but then the\n>> user needs to be careful when to stop (and digging down to the root\n>> of the history, i.e. \"never stop\", may be an acceptable answer to\n>> some projects).\n>\n> I sent a patch to add such an option (which picks the \"never stop\"\n> behavior) on 1st, did you see that?\n>\n> If the idea is OK in principle, but the patch needs tweaking, please let\n> me know.\n\nAs a single-shot change, \"--since-as-filter\" is certainly an easy to\nexplain approach of least resistance.\n\nBut when viewed from a higher level as a general design problem, I\nam unsure if it is a good direction to go in.\n\nGiving \"--since\" the \"as-filter\" variant sets a precedent, and\ncloses the door for a better UI that we can extend more generally\nwithout having to add \"--X-as-filter\" for each and every conceivable\n\"--X\" that is a traversal stopper into a filtering kind.\n\n\n"},{"id":"453342","messageId":"xmqqtub3moa0.fsf@gitster.g","threadId":"57647","inReplyTo":"xmqqv8vkpara.fsf@gitster.g","subject":"Re: git log --since to not stop after first old commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-08T18:19:03Z","receivedAt":"2022-04-08T18:19:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Miklos Vajna writes:\n>\n>> On Fri, Apr 01, 2022 at 10:51:34AM -0700, Junio C Hamano wrote:\n>>> We could add a --since-as-filter= option or something, but then the\n>>> user needs to be careful when to stop (and digging down to the root\n>>> of the history, i.e. \"never stop\", may be an acceptable answer to\n>>> some projects).\n>>\n>> I sent a patch to add such an option (which picks the \"never stop\"\n>> behavior) on 1st, did you see that?\n>>\n>> If the idea is OK in principle, but the patch needs tweaking, please let\n>> me know.\n>\n> As a single-shot change, \"--since-as-filter\" is certainly an easy to\n> explain approach of least resistance.\n>\n> But when viewed from a higher level as a general design problem, I\n> am unsure if it is a good direction to go in.\n>\n> Giving \"--since\" the \"as-filter\" variant sets a precedent, and\n> closes the door for a better UI that we can extend more generally\n> without having to add \"--X-as-filter\" for each and every conceivable\n> \"--X\" that is a traversal stopper into a filtering kind.\n\nIf we pursue the possibility further, perhaps we may realize that\nthere isn't much room for us to add too many \"traversal stoppers\" in\nthe future, in which case giving \"as-filter\" to a very limited few\ntraversal stoppers may not be too bad. I just do not think we have\nexplored that enough to decide that \"--since-as-filter\" is a good UI\n(and it is not a good timing for me to spend brain cycles on the\nissue).\n\nThanks.\n\n"},{"id":"453353","messageId":"YlCiqgO6rL908Zsi@vmiklos.hu","threadId":"57647","inReplyTo":"xmqqtub3moa0.fsf@gitster.g","subject":"[PATCH v3] git-log: add a --since=... --as-filter option","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-08T21:01:30Z","receivedAt":"2022-04-08T21:01:41Z","isPatch":true,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"This is similar to --since, but it will filter out not matching commits,\nrather than stopping at the first not matching commit.\n\nThis is useful if you e.g. want to list the commits from the last year,\nbut one odd commit has a bad commit date and that would hide lots of\nearlier commits in that range.\n\nThe behavior of --since is left unchanged, since it's valid to depend on\nits current behavior.\n\nSigned-off-by: Miklos Vajna \n---\n\nHi Junio,\n\nOn Thu, Apr 07, 2022 at 07:30:33PM -0700, Junio C Hamano wrote:\n> As a single-shot change, \"--since-as-filter\" is certainly an easy to\n> explain approach of least resistance.\n> \n> But when viewed from a higher level as a general design problem, I\n> am unsure if it is a good direction to go in.\n> \n> Giving \"--since\" the \"as-filter\" variant sets a precedent, and\n> closes the door for a better UI that we can extend more generally\n> without having to add \"--X-as-filter\" for each and every conceivable\n> \"--X\" that is a traversal stopper into a filtering kind.\n\nI like the idea of doing this mode as \"--since=... --as-filter\". I can\nstill implement it just for --since=... initially, but it can be\nextended for other flags as well in the future if there is a need.\n\n> If we pursue the possibility further, perhaps we may realize that\n> there isn't much room for us to add too many \"traversal stoppers\" in\n> the future, in which case giving \"as-filter\" to a very limited few\n> traversal stoppers may not be too bad. I just do not think we have\n> explored that enough to decide that \"--since-as-filter\" is a good UI\n\nMy understanding is that get_revision_1() has a special-case for the max\nage case to be a \"traversal stopper\", and all other options are just \nfiltering in limit_range(). But perhaps I missed something.\n\nHere is an updated patch to do the new syntax.\n\nThanks,\n\nMiklos\n\n Documentation/rev-list-options.txt | 5 +++++\n revision.c | 14 +++++++++++--\n revision.h | 1 +\n t/t4217-log-limit.sh | 32 ++++++++++++++++++++++++++++++\n 4 files changed, 50 insertions(+), 2 deletions(-)\n create mode 100755 t/t4217-log-limit.sh\n\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex fd4f4e26c9..8565299264 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -25,6 +25,11 @@ ordering and formatting options, such as `--reverse`.\n --after=::\n \tShow commits more recent than a specific date.\n \n+--as-filter::\n+\tWhen combined with `--since=`, show all commits more recent than\n+\ta specific date. This visits all commits in the range, rather than stopping at\n+\tthe first commit which is older than a specific date.\n+\n --until=::\n --before=::\n \tShow commits older than a specific date.\ndiff --git a/revision.c b/revision.c\nindex 7d435f8048..41ea72e516 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1440,6 +1440,9 @@ static int limit_list(struct rev_info *revs)\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age) &&\n \t\t !revs->line_level_traverse)\n \t\t\tcontinue;\n+\t\tif (revs->max_age != -1 && revs->as_filter && (commit->date < revs->max_age) &&\n+\t\t !revs->line_level_traverse)\n+\t\t\tcontinue;\n \t\tdate = commit->date;\n \t\tp = &commit_list_insert(commit, p)->next;\n \n@@ -1838,6 +1841,7 @@ void repo_init_revisions(struct repository *r,\n \trevs->dense = 1;\n \trevs->prefix = prefix;\n \trevs->max_age = -1;\n+\trevs->as_filter = 0;\n \trevs->min_age = -1;\n \trevs->skip_count = -1;\n \trevs->max_count = -1;\n@@ -2218,6 +2222,9 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if ((argcount = parse_long_opt(\"since\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n+\t} else if (!strcmp(arg, \"--as-filter\")) {\n+\t\trevs->as_filter = 1;\n+\t\treturn argcount;\n \t} else if ((argcount = parse_long_opt(\"after\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n@@ -3365,7 +3372,7 @@ static void explore_walk_step(struct rev_info *revs)\n \tif (revs->sort_order == REV_SORT_BY_AUTHOR_DATE)\n \t\trecord_author_date(&info->author_date, c);\n \n-\tif (revs->max_age != -1 && (c->date < revs->max_age))\n+\tif (revs->max_age != -1 && !revs->as_filter && (c->date < revs->max_age))\n \t\tc->object.flags |= UNINTERESTING;\n \n \tif (process_parents(revs, c, NULL, NULL) < 0)\n@@ -3862,6 +3869,9 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n \tif (revs->min_age != -1 &&\n \t comparison_date(revs, commit) > revs->min_age)\n \t\t\treturn commit_ignore;\n+\tif (revs->max_age != -1 && revs->as_filter &&\n+\t comparison_date(revs, commit) < revs->max_age)\n+\t\t\treturn commit_ignore;\n \tif (revs->min_parents || (revs->max_parents >= 0)) {\n \t\tint n = commit_list_count(commit->parents);\n \t\tif ((n < revs->min_parents) ||\n@@ -4019,7 +4029,7 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\t * that we'd otherwise have done in limit_list().\n \t\t */\n \t\tif (!revs->limited) {\n-\t\t\tif (revs->max_age != -1 &&\n+\t\t\tif (revs->max_age != -1 && !revs->as_filter &&\n \t\t\t comparison_date(revs, commit) < revs->max_age)\n \t\t\t\tcontinue;\n \ndiff --git a/revision.h b/revision.h\nindex 5bc59c7bfe..fe37ebd83d 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -263,6 +263,7 @@ struct rev_info {\n \tint skip_count;\n \tint max_count;\n \ttimestamp_t max_age;\n+\tint as_filter;\n \ttimestamp_t min_age;\n \tint min_parents;\n \tint max_parents;\ndiff --git a/t/t4217-log-limit.sh b/t/t4217-log-limit.sh\nnew file mode 100755\nindex 0000000000..a66830e3d7\n--- /dev/null\n+++ b/t/t4217-log-limit.sh\n@@ -0,0 +1,32 @@\n+#!/bin/sh\n+\n+test_description='git log with filter options limiting the output'\n+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n+\n+. ./test-lib.sh\n+\n+GIT_TEST_COMMIT_GRAPH=0\n+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n+\n+test_expect_success 'setup test' '\n+\tgit init &&\n+\techo a > file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-02-01 0:00\" git commit -m init &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-03-01 0:00\" git commit -m third\n+'\n+\n+test_expect_success 'git log --since-as-filter' '\n+\tgit log --since=\"2022-01-01\" --as-filter --pretty=\"format:%s\" > actual &&\n+\ttest_i18ngrep init actual &&\n+\t! test_i18ngrep second actual &&\n+\ttest_i18ngrep third actual\n+'\n+\n+test_done\n-- \n2.34.1\n\n"},{"id":"453388","messageId":"YlPMuxhpngs+x9n8@vmiklos.hu","threadId":"57647","inReplyTo":"CANgJU+Wr+tKNPfeh4dst-E_LSnoYYmN1easqmkFUA9spp-rpKQ@mail.gmail.com","subject":"Re: git log --since to not stop after first old commit?","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-11T06:37:47Z","receivedAt":"2022-04-11T06:37:56Z","isPatch":false,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"Hi Yves,\n\nOn Sat, Apr 09, 2022 at 06:02:44AM +0200, demerphq wrote:\n> When you do have the cycles perhaps it is worth considering whether\n> splitting it up, so that --as-filter is a modifier for traversal stoppers,\n> would avoid the problem of proliferating options. Eg, instead of saying\n> --since-as-filter you would say --since ... --as-filter.\n\n[PATCH v3] in this thread is meant to implement this. I hope that helps.\n\nRegards,\n\nMiklos\n"},{"id":"453391","messageId":"CANgJU+U31g_27TdFGvZPy6wgk24OrnC8Z0+hZp2zVshEd7LgJg@mail.gmail.com","threadId":"57647","inReplyTo":"YlPMuxhpngs+x9n8@vmiklos.hu","subject":"Re: git log --since to not stop after first old commit?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2022-04-11T09:18:51Z","receivedAt":"2022-04-11T09:19:08Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On Mon, 11 Apr 2022 at 08:37, Miklos Vajna wrote:\n>\n> Hi Yves,\n>\n> On Sat, Apr 09, 2022 at 06:02:44AM +0200, demerphq wrote:\n> > When you do have the cycles perhaps it is worth considering whether\n> > splitting it up, so that --as-filter is a modifier for traversal stoppers,\n> > would avoid the problem of proliferating options. Eg, instead of saying\n> > --since-as-filter you would say --since ... --as-filter.\n>\n> [PATCH v3] in this thread is meant to implement this. I hope that helps.\n\nThat sounds good to me and IMO certainly preferable to a stack of\noptions with the suffix -as-filter. But please be aware that I am not\na person of significance to the git project and my opinion on this\nprobably isn't worth much. I just thought I would point out that it\nmight be a way to cleanly address Junio's concern about option\nproliferation while still giving you what you want.\n\nCheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"453415","messageId":"xmqqilrfk14q.fsf@gitster.g","threadId":"57647","inReplyTo":"CANgJU+Wr+tKNPfeh4dst-E_LSnoYYmN1easqmkFUA9spp-rpKQ@mail.gmail.com","subject":"Re: git log --since to not stop after first old commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-11T16:58:45Z","receivedAt":"2022-04-11T16:58:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"demerphq writes:\n\n> On Sat, 9 Apr 2022 at 02:43, Junio C Hamano wrote:\n>\n>> > Giving \"--since\" the \"as-filter\" variant sets a precedent, and\n>> > closes the door for a better UI that we can extend more generally\n>> > without having to add \"--X-as-filter\" for each and every conceivable\n>> > \"--X\" that is a traversal stopper into a filtering kind.\n>>\n>> If we pursue the possibility further, perhaps we may realize that\n>> there isn't much room for us to add too many \"traversal stoppers\" in\n>> the future, in which case giving \"as-filter\" to a very limited few\n>> traversal stoppers may not be too bad. I just do not think we have\n>> explored that enough to decide that \"--since-as-filter\" is a good UI\n>> (and it is not a good timing for me to spend brain cycles on the\n>> issue).\n>\n> When you do have the cycles perhaps it is worth considering whether\n> splitting it up, so that --as-filter is a modifier for traversal stoppers,\n> would avoid the problem of proliferating options. Eg, instead of saying\n> --since-as-filter you would say --since ... --as-filter. That way the\n> stoppers where \"filter like behavior\" made sense could just check if the\n> --as-filter flag was set.\n\nYes, that has exactly the opposite problem I wanted to warn us about\nby sending an extra message (to which you are reponding to). If we\nhave (or can have) very many traversal stopping option, it might\nmake sense to have --as-filter as a modifier and avoid doubling the\nnumber of options, but if we only have very few (and fundamentally\ncannot have more than very few), then giving each of these very few\n--X its own --X-as-filter variant would probably make more sense.\nBecause end users would probably not know which ones are inherently\nfilters and will not be affected with --as-filter modifier, it would\nhelp them understand if we give them independent --since-as-filter\noption and document it separately, if there aren't many of them.\n\nBesides, if we had very few but still multiple of them, --X and\n--Y-as-filter can be combined to say \"X stops as before, but Y is\napplied as filter\", which is strictly more expressive than a\nseparate --as-filter modifier.\n\nSo that is why I threw out the message for those interested in the\ntopic to first think about. I know we agree that --since may be a\ngood candidate to have these two flavours of behaviour. I do not\nthink anybody carefully thought about existing options to see if\nthere are many like --since that want two flavours, let alone\npossible options we have said in the past that we may want to have\nbut not yet added.\n\nThanks.\n"},{"id":"453437","messageId":"220412.86pmlmhe9a.gmgdl@evledraar.gmail.com","threadId":"57647","inReplyTo":"YlCiqgO6rL908Zsi@vmiklos.hu","subject":"Re: [PATCH v3] git-log: add a --since=... --as-filter option","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-12T08:47:15Z","receivedAt":"2022-04-12T09:59:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 08 2022, Miklos Vajna wrote:\n\n> On Thu, Apr 07, 2022 at 07:30:33PM -0700, Junio C Hamano wrote:\n>> As a single-shot change, \"--since-as-filter\" is certainly an easy to\n>> explain approach of least resistance.\n>> \n>> But when viewed from a higher level as a general design problem, I\n>> am unsure if it is a good direction to go in.\n>> \n>> Giving \"--since\" the \"as-filter\" variant sets a precedent, and\n>> closes the door for a better UI that we can extend more generally\n>> without having to add \"--X-as-filter\" for each and every conceivable\n>> \"--X\" that is a traversal stopper into a filtering kind.\n>\n> I like the idea of doing this mode as \"--since=... --as-filter\". I can\n> still implement it just for --since=... initially, but it can be\n> extended for other flags as well in the future if there is a need.\n\nYes, I think this is much better.\n\n>> If we pursue the possibility further, perhaps we may realize that\n>> there isn't much room for us to add too many \"traversal stoppers\" in\n>> the future, in which case giving \"as-filter\" to a very limited few\n>> traversal stoppers may not be too bad. I just do not think we have\n>> explored that enough to decide that \"--since-as-filter\" is a good UI\n>\n> My understanding is that get_revision_1() has a special-case for the max\n> age case to be a \"traversal stopper\", and all other options are just \n> filtering in limit_range(). But perhaps I missed something.\n> [...]\n> Documentation/rev-list-options.txt | 5 +++++\n> revision.c | 14 +++++++++++--\n> revision.h | 1 +\n> t/t4217-log-limit.sh | 32 ++++++++++++++++++++++++++++++\n> 4 files changed, 50 insertions(+), 2 deletions(-)\n> create mode 100755 t/t4217-log-limit.sh\n>\n> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\n> index fd4f4e26c9..8565299264 100644\n> --- a/Documentation/rev-list-options.txt\n> +++ b/Documentation/rev-list-options.txt\n> @@ -25,6 +25,11 @@ ordering and formatting options, such as `--reverse`.\n> --after=::\n> \tShow commits more recent than a specific date.\n> \n> +--as-filter::\n> +\tWhen combined with `--since=`, show all commits more recent than\n> +\ta specific date. This visits all commits in the range, rather than stopping at\n> +\tthe first commit which is older than a specific date.\n\nI wonder if we should be more future-proof here and say that we'll run\nanything as a filter, and that --since is the one option currently\naffected.\n\nBut maybe there's no reason to do so...\n\nIn any case these docs are inaccurate because they cover --since, but if\nyou check revision.c we'll set \"max_age\" on other options too\n(synonyms?).\n\nAll in all I wonder if this wouldn't be much more understandable if we\nadvertised is as another option to do \"HISTORY SIMPLIFICATION\", which\nlooking at e.g. get_commit_action() and \"prune\" is kind of what we're\ndoing with the existing --since behavior.\n\n> --until=::\n> --before=::\n> \tShow commits older than a specific date.\n> diff --git a/revision.c b/revision.c\n> index 7d435f8048..41ea72e516 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -1440,6 +1440,9 @@ static int limit_list(struct rev_info *revs)\n> \t\tif (revs->min_age != -1 && (commit->date > revs->min_age) &&\n> \t\t !revs->line_level_traverse)\n> \t\t\tcontinue;\n> +\t\tif (revs->max_age != -1 && revs->as_filter && (commit->date < revs->max_age) &&\n> +\t\t !revs->line_level_traverse)\n> +\t\t\tcontinue;\n> \t\tdate = commit->date;\n> \t\tp = &commit_list_insert(commit, p)->next;\n> \n> @@ -1838,6 +1841,7 @@ void repo_init_revisions(struct repository *r,\n> \trevs->dense = 1;\n> \trevs->prefix = prefix;\n> \trevs->max_age = -1;\n> +\trevs->as_filter = 0;\n> \trevs->min_age = -1;\n> \trevs->skip_count = -1;\n> \trevs->max_count = -1;\n> @@ -2218,6 +2222,9 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n> \t} else if ((argcount = parse_long_opt(\"since\", argv, &optarg))) {\n> \t\trevs->max_age = approxidate(optarg);\n> \t\treturn argcount;\n> +\t} else if (!strcmp(arg, \"--as-filter\")) {\n> +\t\trevs->as_filter = 1;\n> +\t\treturn argcount;\n> \t} else if ((argcount = parse_long_opt(\"after\", argv, &optarg))) {\n> \t\trevs->max_age = approxidate(optarg);\n> \t\treturn argcount;\n> @@ -3365,7 +3372,7 @@ static void explore_walk_step(struct rev_info *revs)\n> \tif (revs->sort_order == REV_SORT_BY_AUTHOR_DATE)\n> \t\trecord_author_date(&info->author_date, c);\n> \n> -\tif (revs->max_age != -1 && (c->date < revs->max_age))\n> +\tif (revs->max_age != -1 && !revs->as_filter && (c->date < revs->max_age))\n> \t\tc->object.flags |= UNINTERESTING;\n> \n> \tif (process_parents(revs, c, NULL, NULL) < 0)\n> @@ -3862,6 +3869,9 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n> \tif (revs->min_age != -1 &&\n> \t comparison_date(revs, commit) > revs->min_age)\n> \t\t\treturn commit_ignore;\n> +\tif (revs->max_age != -1 && revs->as_filter &&\n> +\t comparison_date(revs, commit) < revs->max_age)\n> +\t\t\treturn commit_ignore;\n> \tif (revs->min_parents || (revs->max_parents >= 0)) {\n> \t\tint n = commit_list_count(commit->parents);\n> \t\tif ((n < revs->min_parents) ||\n> @@ -4019,7 +4029,7 @@ static struct commit *get_revision_1(struct rev_info *revs)\n> \t\t * that we'd otherwise have done in limit_list().\n> \t\t */\n> \t\tif (!revs->limited) {\n> -\t\t\tif (revs->max_age != -1 &&\n> +\t\t\tif (revs->max_age != -1 && !revs->as_filter &&\n> \t\t\t comparison_date(revs, commit) < revs->max_age)\n> \t\t\t\tcontinue;\n\nI think it's good to do this as a general mechanism, but if you now\nremove the \"max_age\" field from \"struct rev_info\" and:\n\n\tmake -k\n\nYou'll see a bunch of callers who check \"max_age\" outside of revision.c,\nsince those will accept these revision options are they doing the right\nthing now too?\n\n...\n\n> diff --git a/revision.h b/revision.h\n> index 5bc59c7bfe..fe37ebd83d 100644\n> --- a/revision.h\n> +++ b/revision.h\n> @@ -263,6 +263,7 @@ struct rev_info {\n> \tint skip_count;\n> \tint max_count;\n> \ttimestamp_t max_age;\n> +\tint as_filter;\n> \ttimestamp_t min_age;\n> \tint min_parents;\n> \tint max_parents;\n> diff --git a/t/t4217-log-limit.sh b/t/t4217-log-limit.sh\n> new file mode 100755\n> index 0000000000..a66830e3d7\n> --- /dev/null\n> +++ b/t/t4217-log-limit.sh\n> @@ -0,0 +1,32 @@\n> +#!/bin/sh\n> +\n> +test_description='git log with filter options limiting the output'\n> +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n> +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n> +\n> +. ./test-lib.sh\n> +\n> +GIT_TEST_COMMIT_GRAPH=0\n> +GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n> +\n> +test_expect_success 'setup test' '\n> +\tgit init &&\n> +\techo a > file &&\n> +\tgit add file &&\n> +\tGIT_COMMITTER_DATE=\"2022-02-01 0:00\" git commit -m init &&\n> +\techo a >> file &&\n> +\tgit add file &&\n> +\tGIT_COMMITTER_DATE=\"2021-01-01 0:00\" git commit -m second &&\n> +\techo a >> file &&\n> +\tgit add file &&\n> +\tGIT_COMMITTER_DATE=\"2022-03-01 0:00\" git commit -m third\n> +'\n> +\n> +test_expect_success 'git log --since-as-filter' '\n> +\tgit log --since=\"2022-01-01\" --as-filter --pretty=\"format:%s\" > actual &&\n> +\ttest_i18ngrep init actual &&\n> +\t! test_i18ngrep second actual &&\n> +\ttest_i18ngrep third actual\n> +'\n> +\n> +test_done\n\nIn any case we should have tests for those callers, i.e. blame, bundle\netc.\n"},{"id":"453723","messageId":"YlnYDgZRzDI87b/z@vmiklos.hu","threadId":"57647","inReplyTo":"220412.86pmlmhe9a.gmgdl@evledraar.gmail.com","subject":"[PATCH v4] git-log: add a --since=... --as-filter option","fromName":"Miklos Vajna","fromEmail":"vmiklos@vmiklos.hu","sentAt":"2022-04-15T20:39:42Z","receivedAt":"2022-04-15T20:39:52Z","isPatch":true,"sender":{"key":"vmiklos@vmiklos.hu","avatar":"https://avatars.githubusercontent.com/u/13838?v=4"},"body":"This is similar to --since, but it will filter out not matching commits,\nrather than stopping at the first not matching commit.\n\nThis is useful if you e.g. want to list the commits from the last year,\nbut one odd commit has a bad commit date and that would hide lots of\nearlier commits in that range.\n\nThe behavior of --since is left unchanged, since it's valid to depend on\nits current behavior.\n\nSigned-off-by: Miklos Vajna \n---\n\nHi Ævar,\n\nOn Tue, Apr 12, 2022 at 10:47:15AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> > +--as-filter::\n> > +\tWhen combined with `--since=`, show all commits more recent than\n> > +\ta specific date. This visits all commits in the range, rather than stopping at\n> > +\tthe first commit which is older than a specific date.\n> \n> I wonder if we should be more future-proof here and say that we'll run\n> anything as a filter, and that --since is the one option currently\n> affected.\n> \n> But maybe there's no reason to do so...\n\nMy understanding is that in practice --since is the only option that\nterminates the revision walk on the first match, so I would argue there\nis no need for this.\n\n> In any case these docs are inaccurate because they cover --since, but if\n> you check revision.c we'll set \"max_age\" on other options too\n> (synonyms?).\n\nGood catch, I've added --max-age and --after as well.\n\n> All in all I wonder if this wouldn't be much more understandable if we\n> advertised is as another option to do \"HISTORY SIMPLIFICATION\", which\n> looking at e.g. get_commit_action() and \"prune\" is kind of what we're\n> doing with the existing --since behavior.\n\nMakes sense, we kind of simplify history by default here & then this\noption could be documented as one that modifies this terminating\nbehavior.\n\n> I think it's good to do this as a general mechanism, but if you now\n> remove the \"max_age\" field from \"struct rev_info\" and:\n> \n> \tmake -k\n> \n> You'll see a bunch of callers who check \"max_age\" outside of revision.c,\n> since those will accept these revision options are they doing the right\n> thing now too?\n\nI found the following callers:\n\n- some builtins that want to make sure that no history limiting is used,\n an additional --as-filter doesn't change behavior there\n\n- blame: this has its own commit walking loop, so --as-filter doesn't\n change any behavior here unintentionally.\n\n- bundle: --since is not used for revision walking here, just to check\n what tags to include/exclude, so this is already not terminating\n\n> In any case we should have tests for those callers, i.e. blame, bundle\n> etc.\n\nt/t5607-clone-bundle.sh already tests bundle --since. I've added a new\nt/t4218-blame-limit.sh to test blame --since, it seems there were no\ntests for this so far.\n\nThanks,\n\nMiklos\n\n Documentation/rev-list-options.txt | 6 +++++\n revision.c | 13 +++++++++--\n revision.h | 1 +\n t/t4217-log-limit.sh | 36 ++++++++++++++++++++++++++++++\n t/t4218-blame-limit.sh | 36 ++++++++++++++++++++++++++++++\n 5 files changed, 90 insertions(+), 2 deletions(-)\n create mode 100755 t/t4217-log-limit.sh\n create mode 100755 t/t4218-blame-limit.sh\n\ndiff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt\nindex fd4f4e26c9..354bd29f10 100644\n--- a/Documentation/rev-list-options.txt\n+++ b/Documentation/rev-list-options.txt\n@@ -350,6 +350,12 @@ The following options select the commits to be shown:\n ::\n \tCommits modifying the given are selected.\n \n+--as-filter::\n+\tWhen combined with `--max-age=`, `--since=` or\n+\t`--after=`, show all commits more recent than a specific date. This\n+\tvisits all commits in the range, rather than stopping at the first commit\n+\twhich is older than a specific date.\n+\n --simplify-by-decoration::\n \tCommits that are referred by some branch or tag are selected.\n \ndiff --git a/revision.c b/revision.c\nindex 7d435f8048..ff018c3976 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1440,6 +1440,9 @@ static int limit_list(struct rev_info *revs)\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age) &&\n \t\t !revs->line_level_traverse)\n \t\t\tcontinue;\n+\t\tif (revs->max_age != -1 && revs->as_filter && (commit->date < revs->max_age) &&\n+\t\t !revs->line_level_traverse)\n+\t\t\tcontinue;\n \t\tdate = commit->date;\n \t\tp = &commit_list_insert(commit, p)->next;\n \n@@ -1838,6 +1841,7 @@ void repo_init_revisions(struct repository *r,\n \trevs->dense = 1;\n \trevs->prefix = prefix;\n \trevs->max_age = -1;\n+\trevs->as_filter = 0;\n \trevs->min_age = -1;\n \trevs->skip_count = -1;\n \trevs->max_count = -1;\n@@ -2218,6 +2222,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if ((argcount = parse_long_opt(\"since\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n+\t} else if (!strcmp(arg, \"--as-filter\")) {\n+\t\trevs->as_filter = 1;\n \t} else if ((argcount = parse_long_opt(\"after\", argv, &optarg))) {\n \t\trevs->max_age = approxidate(optarg);\n \t\treturn argcount;\n@@ -3365,7 +3371,7 @@ static void explore_walk_step(struct rev_info *revs)\n \tif (revs->sort_order == REV_SORT_BY_AUTHOR_DATE)\n \t\trecord_author_date(&info->author_date, c);\n \n-\tif (revs->max_age != -1 && (c->date < revs->max_age))\n+\tif (revs->max_age != -1 && !revs->as_filter && (c->date < revs->max_age))\n \t\tc->object.flags |= UNINTERESTING;\n \n \tif (process_parents(revs, c, NULL, NULL) < 0)\n@@ -3862,6 +3868,9 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi\n \tif (revs->min_age != -1 &&\n \t comparison_date(revs, commit) > revs->min_age)\n \t\t\treturn commit_ignore;\n+\tif (revs->max_age != -1 && revs->as_filter &&\n+\t comparison_date(revs, commit) < revs->max_age)\n+\t\t\treturn commit_ignore;\n \tif (revs->min_parents || (revs->max_parents >= 0)) {\n \t\tint n = commit_list_count(commit->parents);\n \t\tif ((n < revs->min_parents) ||\n@@ -4019,7 +4028,7 @@ static struct commit *get_revision_1(struct rev_info *revs)\n \t\t * that we'd otherwise have done in limit_list().\n \t\t */\n \t\tif (!revs->limited) {\n-\t\t\tif (revs->max_age != -1 &&\n+\t\t\tif (revs->max_age != -1 && !revs->as_filter &&\n \t\t\t comparison_date(revs, commit) < revs->max_age)\n \t\t\t\tcontinue;\n \ndiff --git a/revision.h b/revision.h\nindex 5bc59c7bfe..fe37ebd83d 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -263,6 +263,7 @@ struct rev_info {\n \tint skip_count;\n \tint max_count;\n \ttimestamp_t max_age;\n+\tint as_filter;\n \ttimestamp_t min_age;\n \tint min_parents;\n \tint max_parents;\ndiff --git a/t/t4217-log-limit.sh b/t/t4217-log-limit.sh\nnew file mode 100755\nindex 0000000000..2a3705c714\n--- /dev/null\n+++ b/t/t4217-log-limit.sh\n@@ -0,0 +1,36 @@\n+#!/bin/sh\n+\n+test_description='git log with filter options limiting the output'\n+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n+\n+. ./test-lib.sh\n+\n+GIT_TEST_COMMIT_GRAPH=0\n+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n+\n+test_expect_success 'setup test' '\n+\tgit init &&\n+\techo a > file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2021-02-01 0:00\" git commit -m init &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-02-01 0:00\" git commit -m first &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2021-03-01 0:00\" git commit -m second &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_COMMITTER_DATE=\"2022-03-01 0:00\" git commit -m third\n+'\n+\n+test_expect_success 'git log --since=... --as-filter' '\n+\tgit log --since=\"2022-01-01\" --as-filter --pretty=\"format:%s\" > actual &&\n+\t! test_i18ngrep init actual &&\n+\ttest_i18ngrep first actual &&\n+\t! test_i18ngrep second actual &&\n+\ttest_i18ngrep third actual\n+'\n+\n+test_done\ndiff --git a/t/t4218-blame-limit.sh b/t/t4218-blame-limit.sh\nnew file mode 100755\nindex 0000000000..03f513f331\n--- /dev/null\n+++ b/t/t4218-blame-limit.sh\n@@ -0,0 +1,36 @@\n+#!/bin/sh\n+\n+test_description='git blame with filter options limiting the output'\n+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main\n+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\n+\n+. ./test-lib.sh\n+\n+GIT_TEST_COMMIT_GRAPH=0\n+GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS=0\n+\n+test_expect_success 'setup test' '\n+\tgit init &&\n+\techo a > file &&\n+\tgit add file &&\n+\tGIT_AUTHOR_DATE=\"2020-01-01 0:00\" GIT_COMMITTER_DATE=\"2020-01-01 0:00\" git commit -m init &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_AUTHOR_DATE=\"2020-02-01 0:00\" GIT_COMMITTER_DATE=\"2020-02-01 0:00\" git commit -m first &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_AUTHOR_DATE=\"2020-03-01 0:00\" GIT_COMMITTER_DATE=\"2020-03-01 0:00\" git commit -m second &&\n+\techo a >> file &&\n+\tgit add file &&\n+\tGIT_AUTHOR_DATE=\"2020-04-01 0:00\" GIT_COMMITTER_DATE=\"2020-04-01 0:00\" git commit -m third\n+'\n+\n+test_expect_success 'git blame --since=...' '\n+\tgit blame --since=\"2020-02-15\" file > actual &&\n+\t! test_i18ngrep 2020-01-01 actual &&\n+\ttest_i18ngrep 2020-02-01 actual &&\n+\ttest_i18ngrep 2020-03-01 actual &&\n+\ttest_i18ngrep 2020-04-01 actual\n+'\n+\n+test_done\n-- \n2.34.1\n\n"},{"id":"453734","messageId":"xmqqmtgm9c01.fsf@gitster.g","threadId":"57647","inReplyTo":"YlnYDgZRzDI87b/z@vmiklos.hu","subject":"Re: [PATCH v4] git-log: add a --since=... --as-filter option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-15T23:13:02Z","receivedAt":"2022-04-15T23:13:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miklos Vajna writes:\n\n> This is similar to --since, but it will filter out not matching commits,\n> rather than stopping at the first not matching commit.\n>\n> This is useful if you e.g. want to list the commits from the last year,\n> but one odd commit has a bad commit date and that would hide lots of\n> earlier commits in that range.\n>\n> The behavior of --since is left unchanged, since it's valid to depend on\n> its current behavior.\n\nThe above is good if it were a new --since-as-filter option. Adding\n\"--as-filter\" as a separate option to be used in conjunction with\n\"--since\" would fundamentally mean \"The behaviour of --since is left\nunchanged\" cannot possibly be true.\n\nA suggested rewrite. I label each section and highlight its point,\nbut in the end product, you should just separate them with a blank\nline, making each of them into its own paragraph.\n\nTitle (single line, short and to the point)\n\n log: \"--as-filter\" option adjusts how \"--since\" cut-off works\n\nIntro (observation of the current state)\n\n The \"--since=