From: Junio C Hamano <gitster@pobox.com>
To: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
Cc: git <git@vger.kernel.org>, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [RFC PATCH 0/3] grep: don't add subrepos to in-memory alternates
Date: Fri, 20 Sep 2019 09:26:28 -0700 [thread overview]
Message-ID: <xmqqh857vsqz.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAHd-oW4u+iPFMvSGNvSJxfPLE34dQQ3x5_aQ-Y4Pd99FXR1p7Q@mail.gmail.com> (Matheus Tavares Bernardino's message of "Thu, 19 Sep 2019 02:18:57 -0300")
Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:
> Hmm, I may have gotten a little confused here. Are you talking
> about the attributes stack (which contains .gitattributes and
> info/attributes)? If so, isn't this stack already rebuild for
> every path? I mean, by the previous call chain it seems to me that
> at least these two files are reread for every path.
Yes, but for the switch that happens when coming out of a normal
directory and then descending into another normal directory is just
to pop the entries from the directory hierarchy we are getting out
of, and then pushing the entries from the new directory hierarchy.
We would not be discarding and rereading $GIT_DIR/info/ or the
.gitattribute file from the top-level of the working tree.
Descending into a submodule is fundamentally and completely
different. None of the attributes defined in the superproject
should affect the paths in the submodule, as it is a totally
separate project, oblivious to the existence of enclosing the
superproject.
Every time we look up attributes for a path in a project (either the
superproject or a submodule) that is different from the one we did a
look-up the last time, we'd not just need to pop a handful and push
a handful, but need to rebuild the stack completely from scratch,
no?
next prev parent reply other threads:[~2019-09-20 16:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 1:56 [RFC PATCH 0/3] grep: don't add subrepos to in-memory alternates Matheus Tavares
2019-09-18 1:56 ` [RFC PATCH 1/3] diff: use the given repo at diff_populate_filespec() Matheus Tavares
2019-09-18 1:56 ` [RFC PATCH 2/3] object: allow parse_object_or_die() to handle any repo Matheus Tavares
2019-09-18 1:56 ` [RFC PATCH 3/3] grep: don't add submodules to the alternates list Matheus Tavares
2019-09-21 21:58 ` Brandon Williams
2019-09-18 19:55 ` [RFC PATCH 0/3] grep: don't add subrepos to in-memory alternates Junio C Hamano
2019-09-19 5:18 ` Matheus Tavares Bernardino
2019-09-20 16:26 ` Junio C Hamano [this message]
2019-09-21 20:34 ` Matheus Tavares Bernardino
2019-09-28 3:24 ` Junio C Hamano
2019-09-28 4:20 ` Matheus Tavares Bernardino
2021-09-27 12:08 [PATCH v3 6/8] grep: add repository to OID grep sources Ævar Arnfjörð Bjarmason
2021-09-27 16:45 ` [RFC PATCH 0/3] grep: don'\''t add subrepos to in-memory alternates Matheus Tavares
2021-09-27 17:30 ` Ævar Arnfjörð Bjarmason
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=xmqqh857vsqz.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=matheus.bernardino@usp.br \
/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.