{"thread":{"id":"12400","subject":"[RFC/PATCH] rename: warn user when we have turned off rename detection","startedAt":"2008-03-01T06:14:31Z","lastAt":"2008-03-01T09:30:56Z","messageCount":4,"participants":["Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"70480","messageId":"20080301061431.GA27301@coredump.intra.peff.net","threadId":"12400","inReplyTo":null,"subject":"[RFC/PATCH] rename: warn user when we have turned off rename detection","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-01T06:14:31Z","receivedAt":"2008-03-01T06:14:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"\nSigned-off-by: Jeff King <peff@peff.net>\n---\nThis was another patch from late in the freeze period. It was in\nresponse to a user getting confused about why rename detection wasn't\nhappening in a large merge. Is it appropriate to print this for every\nrename we try? Or should it just be for merges?\n\nPerhaps we should also bump the default limit from 100, which I think\nwas just arbitrarily chosen. I posted some numbers in:\n\n  http://mid.gmane.org/20080211113516.GB6344@coredump.intra.peff.net\n\nwhich imply that 200-400 is probably a more reasonable value. Thoughts?\n\n diffcore-rename.c |    7 ++++---\n 1 files changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/diffcore-rename.c b/diffcore-rename.c\nindex 3d37725..31941bc 100644\n--- a/diffcore-rename.c\n+++ b/diffcore-rename.c\n@@ -468,10 +468,11 @@ void diffcore_rename(struct diff_options *options)\n \t */\n \tif (rename_limit <= 0 || rename_limit > 32767)\n \t\trename_limit = 32767;\n-\tif (num_create > rename_limit && num_src > rename_limit)\n-\t\tgoto cleanup;\n-\tif (num_create * num_src > rename_limit * rename_limit)\n+\tif ((num_create > rename_limit && num_src > rename_limit) ||\n+\t    (num_create * num_src > rename_limit * rename_limit)) {\n+\t\twarning(\"too many files, skipping inexact rename detection\");\n \t\tgoto cleanup;\n+\t}\n \n \tmx = xmalloc(sizeof(*mx) * num_create * num_src);\n \tfor (dst_cnt = i = 0; i < rename_dst_nr; i++) {\n-- \n1.5.4.3.422.g55194\n"},{"id":"70487","messageId":"7vtzjq6gnv.fsf@gitster.siamese.dyndns.org","threadId":"12400","inReplyTo":"20080301061431.GA27301@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] rename: warn user when we have turned off rename detection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-01T07:35:00Z","receivedAt":"2008-03-01T07:35:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Signed-off-by: Jeff King <peff@peff.net>\n> ---\n> This was another patch from late in the freeze period. It was in\n> response to a user getting confused about why rename detection wasn't\n> happening in a large merge. Is it appropriate to print this for every\n> rename we try? Or should it just be for merges?\n>\n> Perhaps we should also bump the default limit from 100, which I think\n> was just arbitrarily chosen.\n> ...\n> +\tif ((num_create > rename_limit && num_src > rename_limit) ||\n> +\t    (num_create * num_src > rename_limit * rename_limit)) {\n> +\t\twarning(\"too many files, skipping inexact rename detection\");\n>  \t\tgoto cleanup;\n> +\t}\n> \n>  \tmx = xmalloc(sizeof(*mx) * num_create * num_src);\n>  \tfor (dst_cnt = i = 0; i < rename_dst_nr; i++) {\n\nThis reminds me of the 6d24ad9 (Optimize rename detection for a huge diff)\ntopic that reduces the above allocation greatly.  Some benching with the\npatch may prove useful to establish much higher limits, I suspect.\n"},{"id":"70497","messageId":"20080301081832.GB31855@coredump.intra.peff.net","threadId":"12400","inReplyTo":"7vtzjq6gnv.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/PATCH] rename: warn user when we have turned off rename detection","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-01T08:18:33Z","receivedAt":"2008-03-01T08:18:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 29, 2008 at 11:35:00PM -0800, Junio C Hamano wrote:\n\n> > +\tif ((num_create > rename_limit && num_src > rename_limit) ||\n> > +\t    (num_create * num_src > rename_limit * rename_limit)) {\n> > +\t\twarning(\"too many files, skipping inexact rename detection\");\n> >  \t\tgoto cleanup;\n> > +\t}\n> > \n> >  \tmx = xmalloc(sizeof(*mx) * num_create * num_src);\n> >  \tfor (dst_cnt = i = 0; i < rename_dst_nr; i++) {\n> \n> This reminds me of the 6d24ad9 (Optimize rename detection for a huge diff)\n> topic that reduces the above allocation greatly.  Some benching with the\n> patch may prove useful to establish much higher limits, I suspect.\n\nActually, my timings are about the same. While the patch you mentioned\nis nice for reducing the memory consumption, we still have an O(n^2)\nloop.\n\n-Peff\n"},{"id":"70502","messageId":"7vd4qe4wq7.fsf@gitster.siamese.dyndns.org","threadId":"12400","inReplyTo":"20080301081832.GB31855@coredump.intra.peff.net","subject":"Re: [RFC/PATCH] rename: warn user when we have turned off rename detection","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-01T09:30:56Z","receivedAt":"2008-03-01T09:30:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> This reminds me of the 6d24ad9 (Optimize rename detection for a huge diff)\n>> topic that reduces the above allocation greatly.  Some benching with the\n>> patch may prove useful to establish much higher limits, I suspect.\n>\n> Actually, my timings are about the same. While the patch you mentioned\n> is nice for reducing the memory consumption, we still have an O(n^2)\n> loop.\n\nYeah, that one was not about the time but about the space, so it is\nexpected.\n"}]}