From: Joey Hess <id@joeyh.name>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)
Date: Tue, 12 Jul 2016 18:20:54 -0400 [thread overview]
Message-ID: <20160712222054.GA10128@kitenet.net> (raw)
In-Reply-To: <1f76a4d3-68b1-db33-5c7b-dc5ab104a3ef@web.de>
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
Torsten Bögershausen wrote re jh/clean-smudge-annex:
> The thing is that we need to check the file system to find .gitatttibutes,
> even if we just did it 1 nanosecond ago.
>
> So the .gitattributes is done 3 times:
> -1 would_convert_to_git_filter_fd(
> -2 assert(would_convert_to_git_filter_fd(path));
> -3 convert.c/convert_to_git_filter_fd()
>
> The only situation where this could be useful is when the .gitattributes
> change between -1 and -2,
> but then they would have changed between -1 and -3, and convert.c
> will die().
>
> Does it make sense to remove -2 ?
There's less redundant work going on than at first seems, because
.gitattribute files are only read once and cached. Verified by strace.
So, the redundant work is only in the processing that convert_attrs() does
of the cached .gitattributes.
Notice that there was a similar redundant triple call to convert_attrs()
before my patch set:
1. index_fd checks would_convert_to_git_filter_fd
2. index_stream_convert_blob does assert(would_convert_to_git_filter_fd(path))
(Again redundantly since 1. is its only caller and has already
checked.)
3. in convert_to_git_filter_fd
If convert_attrs() is somehow expensive, it might be worth passing a
struct conv_attrs * into the functions that currently call
convert_attrs(). But it does not look expensive to me.
I think it would be safe enough to remove both asserts, at least as the
code is structured now.
--
see shy jo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
next prev parent reply other threads:[~2016-07-12 22:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-17 3:20 What's cooking in git.git (Jun 2016, #05; Thu, 16) Junio C Hamano
2016-06-17 13:25 ` Pranit Bauva
2016-06-17 17:55 ` Vasco Almeida
2016-06-17 22:05 ` Lars Schneider
2016-06-17 22:17 ` Junio C Hamano
2016-06-18 17:09 ` Michael Haggerty
2016-06-19 7:59 ` Michael Haggerty
2016-06-19 15:04 ` Lars Schneider
2016-06-19 16:11 ` Lars Schneider
2016-06-19 18:13 ` Junio C Hamano
2016-06-19 18:49 ` Lars Schneider
2016-06-19 18:53 ` Lars Schneider
2016-06-19 18:09 ` Junio C Hamano
2016-06-19 23:51 ` Junio C Hamano
2016-06-20 7:57 ` Lars Schneider
2016-06-23 7:32 ` Michael Haggerty
2016-06-27 7:09 ` Lars Schneider
2016-06-27 16:29 ` Junio C Hamano
2016-06-28 9:23 ` Michael Haggerty
2016-06-28 17:44 ` Junio C Hamano
2016-06-18 4:18 ` Michael Haggerty
2016-06-18 18:20 ` Junio C Hamano
2016-06-19 8:15 ` Michael Haggerty
2016-06-19 18:07 ` Junio C Hamano
2016-06-20 6:06 ` Torsten Bögershausen
2016-06-20 20:06 ` Junio C Hamano
2016-06-22 21:09 ` Joey Hess
2016-06-23 13:13 ` Torsten Bögershausen
2016-07-12 22:20 ` Joey Hess [this message]
2016-07-14 2:09 ` Torsten Bögershausen
2016-07-14 18:17 ` Junio C Hamano
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=20160712222054.GA10128@kitenet.net \
--to=id@joeyh.name \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@web.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).