All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
To: Junio C Hamano <gitster@pobox.com>
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: Sat, 28 Sep 2019 01:20:14 -0300	[thread overview]
Message-ID: <CAHd-oW6uG1fap-T4UF17bJmjoHAqWCDq9KbY+_8a3cEnnfATxg@mail.gmail.com> (raw)
In-Reply-To: <xmqqtv8xksrs.fsf@gitster-ct.c.googlers.com>

On Sat, Sep 28, 2019 at 12:24 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:
>
> > Right, this would be the best way of doing it. However, I think this
> > is not how it's currently implemented. I if correctly understood the
> > code in this call chain:
> >
> > grep_source_load_driver() >  userdiff_find_by_path() >
> > git_check_attr() > collect_some_attrs() > prepare_attr_stack() >
> > bootstrap_attr_stack()
> >
> > it seems that the whole stack is being rebuild for every path (even
> > for paths descending in the same superproject or submodule).
>
> bootstrap is guarded with "if (*stack) return;" and prepare knows to
> rewind to the common level and push down the new ones, no?

Right, I've somehow missed this guard and the fact that 'check' is
static at userdiff_find_by_path() so the stack is persistent. Thanks
for pointing this out and sorry for the noise.

  reply	other threads:[~2019-09-28  4:23 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
2019-09-21 20:34       ` Matheus Tavares Bernardino
2019-09-28  3:24         ` Junio C Hamano
2019-09-28  4:20           ` Matheus Tavares Bernardino [this message]
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=CAHd-oW6uG1fap-T4UF17bJmjoHAqWCDq9KbY+_8a3cEnnfATxg@mail.gmail.com \
    --to=matheus.bernardino@usp.br \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /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.