{"thread":{"id":"49736","subject":"[PATCH 0/3] mixed bag of -Wunused-parameter bugfixes","startedAt":"2018-11-02T05:22:59Z","lastAt":"2018-11-07T02:08:44Z","messageCount":7,"participants":["Jeff King","Carlo Arenas","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"362235","messageId":"20181102052239.GA19162@sigill.intra.peff.net","threadId":"49736","inReplyTo":null,"subject":"[PATCH 0/3] mixed bag of -Wunused-parameter bugfixes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-02T05:22:39Z","receivedAt":"2018-11-02T05:22:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Here are three minor bug-fixes that can be applied independently. The\ncommon thread is that I found them by looking at the results of\ncompiling with -Wunused-parameter. In each of these cases, the parameter\n_should_ be used, and not doing so was a bug.\n\n [1/3]: rev-list: handle flags for --indexed-objects\n [2/3]: approxidate: handle pending number for \"specials\"\n [3/3]: pathspec: handle non-terminated strings with :(attr)\n\n date.c | 60 ++++++++++++++++++++++------------------\n dir.c | 7 +++++\n revision.c | 15 ++++++----\n t/t0006-date.sh | 1 +\n t/t6000-rev-list-misc.sh | 7 +++++\n 5 files changed, 57 insertions(+), 33 deletions(-)\n\n-Peff\n"},{"id":"362237","messageId":"20181102052258.GA19234@sigill.intra.peff.net","threadId":"49736","inReplyTo":"20181102052239.GA19162@sigill.intra.peff.net","subject":"[PATCH 1/3] rev-list: handle flags for --indexed-objects","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-02T05:22:59Z","receivedAt":"2018-11-02T05:23:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When a traversal sees the --indexed-objects option, it adds\nall blobs and valid cache-trees from the index to the\ntraversal using add_index_objects_to_pending(). But that\nfunction totally ignores its flags parameter!\n\nThat means that doing:\n\n git rev-list --objects --indexed-objects\n\nand\n\n git rev-list --objects --not --indexed-objects\n\nproduce the same output, because we ignore the UNINTERESTING\nflag when walking the index in the second example.\n\nNobody noticed because this feature was added as a way for\ntools like repack to increase their coverage of reachable\nobjects, meaning it would only be used like the first\nexample above.\n\nBut since it's user facing (and because the documentation\ndescribes it \"as if the objects are listed on the command\nline\"), we should make sure the negative case behaves\nsensibly.\n\nSigned-off-by: Jeff King \n---\n revision.c | 15 +++++++++------\n t/t6000-rev-list-misc.sh | 7 +++++++\n 2 files changed, 16 insertions(+), 6 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex a1ddb9e11c..8e56c9641f 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1321,13 +1321,14 @@ void add_reflogs_to_pending(struct rev_info *revs, unsigned flags)\n }\n \n static void add_cache_tree(struct cache_tree *it, struct rev_info *revs,\n-\t\t\t struct strbuf *path)\n+\t\t\t struct strbuf *path, unsigned int flags)\n {\n \tsize_t baselen = path->len;\n \tint i;\n \n \tif (it->entry_count >= 0) {\n \t\tstruct tree *tree = lookup_tree(revs->repo, &it->oid);\n+\t\ttree->object.flags |= flags;\n \t\tadd_pending_object_with_path(revs, &tree->object, \"\",\n \t\t\t\t\t 040000, path->buf);\n \t}\n@@ -1335,14 +1336,15 @@ static void add_cache_tree(struct cache_tree *it, struct rev_info *revs,\n \tfor (i = 0; i < it->subtree_nr; i++) {\n \t\tstruct cache_tree_sub *sub = it->down[i];\n \t\tstrbuf_addf(path, \"%s%s\", baselen ? \"/\" : \"\", sub->name);\n-\t\tadd_cache_tree(sub->cache_tree, revs, path);\n+\t\tadd_cache_tree(sub->cache_tree, revs, path, flags);\n \t\tstrbuf_setlen(path, baselen);\n \t}\n \n }\n \n static void do_add_index_objects_to_pending(struct rev_info *revs,\n-\t\t\t\t\t struct index_state *istate)\n+\t\t\t\t\t struct index_state *istate,\n+\t\t\t\t\t unsigned int flags)\n {\n \tint i;\n \n@@ -1356,13 +1358,14 @@ static void do_add_index_objects_to_pending(struct rev_info *revs,\n \t\tblob = lookup_blob(revs->repo, &ce->oid);\n \t\tif (!blob)\n \t\t\tdie(\"unable to add index blob to traversal\");\n+\t\tblob->object.flags |= flags;\n \t\tadd_pending_object_with_path(revs, &blob->object, \"\",\n \t\t\t\t\t ce->ce_mode, ce->name);\n \t}\n \n \tif (istate->cache_tree) {\n \t\tstruct strbuf path = STRBUF_INIT;\n-\t\tadd_cache_tree(istate->cache_tree, revs, &path);\n+\t\tadd_cache_tree(istate->cache_tree, revs, &path, flags);\n \t\tstrbuf_release(&path);\n \t}\n }\n@@ -1372,7 +1375,7 @@ void add_index_objects_to_pending(struct rev_info *revs, unsigned int flags)\n \tstruct worktree **worktrees, **p;\n \n \tread_index(revs->repo->index);\n-\tdo_add_index_objects_to_pending(revs, revs->repo->index);\n+\tdo_add_index_objects_to_pending(revs, revs->repo->index, flags);\n \n \tif (revs->single_worktree)\n \t\treturn;\n@@ -1388,7 +1391,7 @@ void add_index_objects_to_pending(struct rev_info *revs, unsigned int flags)\n \t\tif (read_index_from(&istate,\n \t\t\t\t worktree_git_path(wt, \"index\"),\n \t\t\t\t get_worktree_git_dir(wt)) > 0)\n-\t\t\tdo_add_index_objects_to_pending(revs, &istate);\n+\t\t\tdo_add_index_objects_to_pending(revs, &istate, flags);\n \t\tdiscard_index(&istate);\n \t}\n \tfree_worktrees(worktrees);\ndiff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh\nindex fb4d295aa0..0507999729 100755\n--- a/t/t6000-rev-list-misc.sh\n+++ b/t/t6000-rev-list-misc.sh\n@@ -90,11 +90,18 @@ test_expect_success 'rev-list can show index objects' '\n \t9200b628cf9dc883a85a7abc8d6e6730baee589c two\n \tEOF\n \techo only-in-index >only-in-index &&\n+\ttest_when_finished \"git reset --hard\" &&\n \tgit add only-in-index &&\n \tgit rev-list --objects --indexed-objects >actual &&\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'rev-list can negate index objects' '\n+\tgit rev-parse HEAD >expect &&\n+\tgit rev-list -1 --objects HEAD --not --indexed-objects >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_expect_success '--bisect and --first-parent can not be combined' '\n \ttest_must_fail git rev-list --bisect --first-parent HEAD\n '\n-- \n2.19.1.1336.g081079ac04\n\n"},{"id":"362238","messageId":"20181102052309.GB19234@sigill.intra.peff.net","threadId":"49736","inReplyTo":"20181102052239.GA19162@sigill.intra.peff.net","subject":"[PATCH 2/3] approxidate: handle pending number for \"specials\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-02T05:23:09Z","receivedAt":"2018-11-02T05:23:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The approxidate parser has a table of special keywords like\n\"yesterday\", \"noon\", \"pm\", etc. Some of these, like \"pm\", do\nthe right thing if we've recently seen a number: \"3pm\" is\nwhat you'd think.\n\nHowever, most of them do not look at or modify the\npending-number flag at all, which means a number may \"jump\"\nacross a significant keyword and be used unexpectedly. For\nexample, when parsing:\n\n January 5th noon pm\n\nwe'd connect the \"5\" to \"pm\", and ignore it as a\nday-of-month. This is obviously a bit silly, as \"noon\"\nalready implies \"pm\". And other mis-parsed things are\ngenerally as silly (\"January 5th noon, years ago\" would\nconnect the 5 to \"years\", but probably nobody would type\nthat).\n\nHowever, the fix is simple: when we see a keyword like\n\"noon\", we should flush the pending number (as we would if\nwe hit another number, or the end of the string). In a few\nof the specials that actually modify the day, we can simply\nthrow away the number (saying \"Jan 5 yesterday\" should not\nrespect the number at all).\n\nNote that we have to either move or forward-declare the\nstatic pending_number() to make it accessible to these\nfunctions; this patch moves it.\n\nSigned-off-by: Jeff King \n---\n date.c | 60 +++++++++++++++++++++++++++----------------------\n t/t0006-date.sh | 1 +\n 2 files changed, 34 insertions(+), 27 deletions(-)\n\ndiff --git a/date.c b/date.c\nindex 49f943e25b..7adce327a3 100644\n--- a/date.c\n+++ b/date.c\n@@ -887,13 +887,42 @@ static time_t update_tm(struct tm *tm, struct tm *now, time_t sec)\n \treturn n;\n }\n \n+/*\n+ * Do we have a pending number at the end, or when\n+ * we see a new one? Let's assume it's a month day,\n+ * as in \"Dec 6, 1992\"\n+ */\n+static void pending_number(struct tm *tm, int *num)\n+{\n+\tint number = *num;\n+\n+\tif (number) {\n+\t\t*num = 0;\n+\t\tif (tm->tm_mday < 0 && number < 32)\n+\t\t\ttm->tm_mday = number;\n+\t\telse if (tm->tm_mon < 0 && number < 13)\n+\t\t\ttm->tm_mon = number-1;\n+\t\telse if (tm->tm_year < 0) {\n+\t\t\tif (number > 1969 && number < 2100)\n+\t\t\t\ttm->tm_year = number - 1900;\n+\t\t\telse if (number > 69 && number < 100)\n+\t\t\t\ttm->tm_year = number;\n+\t\t\telse if (number < 38)\n+\t\t\t\ttm->tm_year = 100 + number;\n+\t\t\t/* We screw up for number = 00 ? */\n+\t\t}\n+\t}\n+}\n+\n static void date_now(struct tm *tm, struct tm *now, int *num)\n {\n+\t*num = 0;\n \tupdate_tm(tm, now, 0);\n }\n \n static void date_yesterday(struct tm *tm, struct tm *now, int *num)\n {\n+\t*num = 0;\n \tupdate_tm(tm, now, 24*60*60);\n }\n \n@@ -908,16 +937,19 @@ static void date_time(struct tm *tm, struct tm *now, int hour)\n \n static void date_midnight(struct tm *tm, struct tm *now, int *num)\n {\n+\tpending_number(tm, num);\n \tdate_time(tm, now, 0);\n }\n \n static void date_noon(struct tm *tm, struct tm *now, int *num)\n {\n+\tpending_number(tm, num);\n \tdate_time(tm, now, 12);\n }\n \n static void date_tea(struct tm *tm, struct tm *now, int *num)\n {\n+\tpending_number(tm, num);\n \tdate_time(tm, now, 17);\n }\n \n@@ -953,6 +985,7 @@ static void date_never(struct tm *tm, struct tm *now, int *num)\n {\n \ttime_t n = 0;\n \tlocaltime_r(&n, tm);\n+\t*num = 0;\n }\n \n static const struct special {\n@@ -1110,33 +1143,6 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num,\n \treturn end;\n }\n \n-/*\n- * Do we have a pending number at the end, or when\n- * we see a new one? Let's assume it's a month day,\n- * as in \"Dec 6, 1992\"\n- */\n-static void pending_number(struct tm *tm, int *num)\n-{\n-\tint number = *num;\n-\n-\tif (number) {\n-\t\t*num = 0;\n-\t\tif (tm->tm_mday < 0 && number < 32)\n-\t\t\ttm->tm_mday = number;\n-\t\telse if (tm->tm_mon < 0 && number < 13)\n-\t\t\ttm->tm_mon = number-1;\n-\t\telse if (tm->tm_year < 0) {\n-\t\t\tif (number > 1969 && number < 2100)\n-\t\t\t\ttm->tm_year = number - 1900;\n-\t\t\telse if (number > 69 && number < 100)\n-\t\t\t\ttm->tm_year = number;\n-\t\t\telse if (number < 38)\n-\t\t\t\ttm->tm_year = 100 + number;\n-\t\t\t/* We screw up for number = 00 ? */\n-\t\t}\n-\t}\n-}\n-\n static timestamp_t approxidate_str(const char *date,\n \t\t\t\t const struct timeval *tv,\n \t\t\t\t int *error_ret)\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex 64ff86df8e..b7ea5fbc36 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -113,6 +113,7 @@ check_approxidate '3:00' '2009-08-30 03:00:00'\n check_approxidate '15:00' '2009-08-30 15:00:00'\n check_approxidate 'noon today' '2009-08-30 12:00:00'\n check_approxidate 'noon yesterday' '2009-08-29 12:00:00'\n+check_approxidate 'January 5th noon pm' '2009-01-05 12:00:00'\n \n check_approxidate 'last tuesday' '2009-08-25 19:20:00'\n check_approxidate 'July 5th' '2009-07-05 19:20:00'\n-- \n2.19.1.1336.g081079ac04\n\n"},{"id":"362239","messageId":"20181102052322.GC19234@sigill.intra.peff.net","threadId":"49736","inReplyTo":"20181102052239.GA19162@sigill.intra.peff.net","subject":"[PATCH 3/3] pathspec: handle non-terminated strings with :(attr)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-02T05:23:22Z","receivedAt":"2018-11-02T05:23:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The pathspec code always takes names to be matched as a\nname/namelen pair, but match_attrs() never looks at namelen,\nand just treats \"name\" like a NUL-terminated string, passing\nit to git_check_attr().\n\nThis usually works anyway. Every caller passes a\nNUL-terminated string, and in all but one the passed-in\nlength is the same as the length of the string (the\nexception is dir_path_match(), which may pass a smaller\nlength to drop a trailing slash). So we won't currently ever\nread random memory, and the one case I found actually\nhappens to work correctly because the attr code can handle\nthe trailing slash itself.\n\nBut it's still worth addressing, as the function interface\nimplies that the name does not have to be NUL-terminated,\nmaking this an accident waiting to happen.\n\nSince teaching git_check_attr() to take a ptr/len pair would\nbe a big refactor, we'll just allocate a new string. We can\ndo this only when necessary, which avoids paying the cost\nfor most callers.\n\nSigned-off-by: Jeff King \n---\n dir.c | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/dir.c b/dir.c\nindex 47c2fca8dc..ab6477d777 100644\n--- a/dir.c\n+++ b/dir.c\n@@ -281,8 +281,15 @@ static int match_attrs(const struct index_state *istate,\n \t\t const struct pathspec_item *item)\n {\n \tint i;\n+\tchar *to_free = NULL;\n+\n+\tif (name[namelen])\n+\t\tname = to_free = xmemdupz(name, namelen);\n \n \tgit_check_attr(istate, name, item->attr_check);\n+\n+\tfree(to_free);\n+\n \tfor (i = 0; i < item->attr_match_nr; i++) {\n \t\tconst char *value;\n \t\tint matched;\n-- \n2.19.1.1336.g081079ac04\n"},{"id":"362622","messageId":"CAPUEspi12TtKxKGr=tutfLPNPWhaZmGCh7q4D1LRJ9LFTWwKNA@mail.gmail.com","threadId":"49736","inReplyTo":"20181102052309.GB19234@sigill.intra.peff.net","subject":"Re: [PATCH 2/3] approxidate: handle pending number for \"specials\"","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2018-11-07T00:48:28Z","receivedAt":"2018-11-07T00:48:43Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Thu, Nov 1, 2018 at 10:24 PM Jeff King wrote:\n>\n> static void date_yesterday(struct tm *tm, struct tm *now, int *num)\n> {\n> + *num = 0;\n\nthe only caller (date_time) for this sends num = NULL, so this\ntriggers a segfault.\n\nthe only reference I could find to that apparently unused parameter comes from:\n93cfa7c7a8 (\"approxidate_careful() reports errorneous date string\", 2010-01-26)\nand seems to indicate it is optional and therefore a check for NULL\nmight make sense for all other cases\n\nCarlo\n"},{"id":"362624","messageId":"20181107011253.GA18276@sigill.intra.peff.net","threadId":"49736","inReplyTo":"CAPUEspi12TtKxKGr=tutfLPNPWhaZmGCh7q4D1LRJ9LFTWwKNA@mail.gmail.com","subject":"Re: [PATCH 2/3] approxidate: handle pending number for \"specials\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-11-07T01:12:53Z","receivedAt":"2018-11-07T01:12:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 06, 2018 at 04:48:28PM -0800, Carlo Arenas wrote:\n\n> On Thu, Nov 1, 2018 at 10:24 PM Jeff King wrote:\n> >\n> > static void date_yesterday(struct tm *tm, struct tm *now, int *num)\n> > {\n> > + *num = 0;\n> \n> the only caller (date_time) for this sends num = NULL, so this\n> triggers a segfault.\n\nOof. Thanks for catching.\n\nThat's not the only caller. Usually this is called via a function\npointer from the \"struct special\" array. date_time() is just reusing the\nother helper as a quick way to do a one-day subtraction.\n\n> the only reference I could find to that apparently unused parameter comes from:\n> 93cfa7c7a8 (\"approxidate_careful() reports errorneous date string\", 2010-01-26)\n> and seems to indicate it is optional and therefore a check for NULL\n> might make sense for all other cases\n\nI think date_yesterday() is the only one of those special functions that\ngets called like this. Here's what I think we should do to fix it (this\ncan go right on top of jk/misc-unused-fixes, which is already in next).\n\n-- >8 --\nSubject: [PATCH] approxidate: fix NULL dereference in date_time()\n\nWhen we see a time like \"noon\", we pass \"12\" to our date_time() helper,\nwhich sets the hour to 12pm. If the current time is before noon, then we\nwrap around to yesterday using date_yesterday(). But unlike the normal\ncalls to date_yesterday() from approxidate_alpha(), we pass a NULL \"num\"\nparameter. Since c27cc94fad (approxidate: handle pending number for\n\"specials\", 2018-11-02), that causes a segfault.\n\nOne way to fix this is by checking for NULL. But arguably date_time() is\nabusing our helper by passing NULL in the first place (and this is the\nonly case where one of these \"special\" parsers is used this way). So\ninstead, let's have it just do the 1-day subtraction itself. It's still\njust a one-liner due to our update_tm() helper.\n\nNote that the test added here is a little funny, as we say \"10am noon\",\nwhich makes the \"10am\" seem pointless. But this bug can only be\ntriggered when it the currently-parsed hour is before the special time.\nThe latest special time is \"tea\" at 1700, but t0006 uses a hard-coded\nTEST_DATE_NOW of 1900. We could reset TEST_DATE_NOW, but that may lead\nto confusion in other tests. Just saying \"10am noon\" makes this test\nself-contained.\n\nReported-by: Carlo Arenas \nSigned-off-by: Jeff King \n---\n date.c | 2 +-\n t/t0006-date.sh | 1 +\n 2 files changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/date.c b/date.c\nindex 7adce327a3..9bc15df6f9 100644\n--- a/date.c\n+++ b/date.c\n@@ -929,7 +929,7 @@ static void date_yesterday(struct tm *tm, struct tm *now, int *num)\n static void date_time(struct tm *tm, struct tm *now, int hour)\n {\n \tif (tm->tm_hour < hour)\n-\t\tdate_yesterday(tm, now, NULL);\n+\t\tupdate_tm(tm, now, 24*60*60);\n \ttm->tm_hour = hour;\n \ttm->tm_min = 0;\n \ttm->tm_sec = 0;\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex b7ea5fbc36..ffb2975e48 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -114,6 +114,7 @@ check_approxidate '15:00' '2009-08-30 15:00:00'\n check_approxidate 'noon today' '2009-08-30 12:00:00'\n check_approxidate 'noon yesterday' '2009-08-29 12:00:00'\n check_approxidate 'January 5th noon pm' '2009-01-05 12:00:00'\n+check_approxidate '10am noon' '2009-08-29 12:00:00'\n \n check_approxidate 'last tuesday' '2009-08-25 19:20:00'\n check_approxidate 'July 5th' '2009-07-05 19:20:00'\n-- \n2.19.1.1534.g3beb3b7d96\n\n"},{"id":"362629","messageId":"xmqqbm71d4gp.fsf@gitster-ct.c.googlers.com","threadId":"49736","inReplyTo":"20181107011253.GA18276@sigill.intra.peff.net","subject":"Re: [PATCH 2/3] approxidate: handle pending number for \"specials\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-11-07T02:08:38Z","receivedAt":"2018-11-07T02:08:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Nov 06, 2018 at 04:48:28PM -0800, Carlo Arenas wrote:\n>\n> I think date_yesterday() is the only one of those special functions that\n> gets called like this. Here's what I think we should do to fix it (this\n> can go right on top of jk/misc-unused-fixes, which is already in next).\n\nThanks, both. I think the patch makes sense.\n\n> -- >8 --\n> Subject: [PATCH] approxidate: fix NULL dereference in date_time()\n>\n> When we see a time like \"noon\", we pass \"12\" to our date_time() helper,\n> which sets the hour to 12pm. If the current time is before noon, then we\n> wrap around to yesterday using date_yesterday(). But unlike the normal\n> calls to date_yesterday() from approxidate_alpha(), we pass a NULL \"num\"\n> parameter. Since c27cc94fad (approxidate: handle pending number for\n> \"specials\", 2018-11-02), that causes a segfault.\n>\n> One way to fix this is by checking for NULL. But arguably date_time() is\n> abusing our helper by passing NULL in the first place (and this is the\n> only case where one of these \"special\" parsers is used this way). So\n> instead, let's have it just do the 1-day subtraction itself. It's still\n> just a one-liner due to our update_tm() helper.\n>\n> Note that the test added here is a little funny, as we say \"10am noon\",\n> which makes the \"10am\" seem pointless. But this bug can only be\n> triggered when it the currently-parsed hour is before the special time.\n> The latest special time is \"tea\" at 1700, but t0006 uses a hard-coded\n> TEST_DATE_NOW of 1900. We could reset TEST_DATE_NOW, but that may lead\n> to confusion in other tests. Just saying \"10am noon\" makes this test\n> self-contained.\n>\n> Reported-by: Carlo Arenas \n> Signed-off-by: Jeff King \n> ---\n> date.c | 2 +-\n> t/t0006-date.sh | 1 +\n> 2 files changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/date.c b/date.c\n> index 7adce327a3..9bc15df6f9 100644\n> --- a/date.c\n> +++ b/date.c\n> @@ -929,7 +929,7 @@ static void date_yesterday(struct tm *tm, struct tm *now, int *num)\n> static void date_time(struct tm *tm, struct tm *now, int hour)\n> {\n> \tif (tm->tm_hour < hour)\n> -\t\tdate_yesterday(tm, now, NULL);\n> +\t\tupdate_tm(tm, now, 24*60*60);\n> \ttm->tm_hour = hour;\n> \ttm->tm_min = 0;\n> \ttm->tm_sec = 0;\n> diff --git a/t/t0006-date.sh b/t/t0006-date.sh\n> index b7ea5fbc36..ffb2975e48 100755\n> --- a/t/t0006-date.sh\n> +++ b/t/t0006-date.sh\n> @@ -114,6 +114,7 @@ check_approxidate '15:00' '2009-08-30 15:00:00'\n> check_approxidate 'noon today' '2009-08-30 12:00:00'\n> check_approxidate 'noon yesterday' '2009-08-29 12:00:00'\n> check_approxidate 'January 5th noon pm' '2009-01-05 12:00:00'\n> +check_approxidate '10am noon' '2009-08-29 12:00:00'\n> \n> check_approxidate 'last tuesday' '2009-08-25 19:20:00'\n> check_approxidate 'July 5th' '2009-07-05 19:20:00'\n"}]}