All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] dir: point treat_leading_path() warning to the right place
Date: Wed, 15 Jan 2020 12:28:48 -0800	[thread overview]
Message-ID: <CABPp-BFQDkpcm57dTwH+AiMsocxTro4ZuvhK2eAZzfHutWjq3Q@mail.gmail.com> (raw)
In-Reply-To: <20200115202146.GA4091171@coredump.intra.peff.net>

On Wed, Jan 15, 2020 at 12:21 PM Jeff King <peff@peff.net> wrote:
>
> On Wed, Jan 15, 2020 at 02:21:18PM +0000, Elijah Newren via GitGitGadget wrote:
>
> > From: Jeff King <peff@peff.net>
> >
> > Restructure the code slightly to avoid passing around a struct dirent
> > anywhere, which also enables us to avoid trying to manufacture one.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > Signed-off-by: Elijah Newren <newren@gmail.com>
>
> Thanks, this looks good.
>
> I wondered briefly whether this:
>
> > @@ -2374,12 +2362,13 @@ static int treat_leading_path(struct dir_struct *dir,
> >                       break;
> >               strbuf_reset(&sb);
> >               strbuf_add(&sb, path, prevlen);
> > -             memcpy(de->d_name, path+prevlen, baselen-prevlen);
> > -             de->d_name[baselen-prevlen] = '\0';
> > +             strbuf_reset(&subdir);
> > +             strbuf_add(&subdir, path+prevlen, baselen-prevlen);
> > +             cdir.d_name = subdir.buf;
>
> ...could avoid the extra strbuf by pointing into an existing string
> (since d_name is now a pointer, and not part of a dirent). But I think
> the answer is "no", because in a path like "a/b/c", the loop may see
> just "b" (so offsetting into path isn't sufficient, because we also have
> to cut off the trailing part).
>
> I did notice one other small thing while looking at this code:
>
> -- >8 --
> Subject: [PATCH] dir: point treat_leading_path() warning to the right place
>
> Commit 777b420347 (dir: synchronize treat_leading_path() and
> read_directory_recursive(), 2019-12-19) tried to add two warning
> comments in those functions, pointing at each other. But the one in
> treat_leading_path() just points at itself.
>
> Let's fix that. Since the comment also redirects the reader for more
> details to "the commit that added this warning", and since we're now
> modifying the warning (creating a new commit without those details),
> let's mention the actual commit id.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  dir.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/dir.c b/dir.c
> index 7d255227b1..31e83d982a 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2308,9 +2308,9 @@ static int treat_leading_path(struct dir_struct *dir,
>          * WARNING WARNING WARNING:
>          *
>          * Any updates to the traversal logic here may need corresponding
> -        * updates in treat_leading_path().  See the commit message for the
> -        * commit adding this warning as well as the commit preceding it
> -        * for details.
> +        * updates in read_directory_recursive().  See 777b420347 (dir:
> +        * synchronize treat_leading_path() and read_directory_recursive(),
> +        * 2019-12-19) and its parent commit for details.
>          */
>
>         struct strbuf sb = STRBUF_INIT;
> --
> 2.25.0.639.gb9b1511416

Looks good to me; thanks.

  reply	other threads:[~2020-01-15 20:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 16:32 [PATCH] dir: restructure in a way to avoid passing around a struct dirent Elijah Newren via GitGitGadget
2020-01-14 21:07 ` Johannes Schindelin
2020-01-14 21:13   ` Elijah Newren
2020-01-14 22:03 ` Jeff King
2020-01-15 14:21 ` [PATCH v2] " Elijah Newren via GitGitGadget
2020-01-15 20:21   ` [PATCH] dir: point treat_leading_path() warning to the right place Jeff King
2020-01-15 20:28     ` Elijah Newren [this message]
2020-01-16 20:21   ` [PATCH v3 0/4] dir: more fill_directory() fixes Elijah Newren via GitGitGadget
2020-01-16 20:21     ` [PATCH v3 1/4] clean: demonstrate a bug with pathspecs Derrick Stolee via GitGitGadget
2020-01-17 15:20       ` Derrick Stolee
2020-01-17 16:53         ` Elijah Newren
2020-01-16 20:21     ` [PATCH v3 2/4] dir: treat_leading_path() and read_directory_recursive(), round 2 Elijah Newren via GitGitGadget
2020-01-17 15:25       ` Derrick Stolee
2020-01-16 20:21     ` [PATCH v3 3/4] dir: restructure in a way to avoid passing around a struct dirent Jeff King via GitGitGadget
2020-01-16 20:21     ` [PATCH v3 4/4] dir: point treat_leading_path() warning to the right place Jeff King via GitGitGadget

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=CABPp-BFQDkpcm57dTwH+AiMsocxTro4ZuvhK2eAZzfHutWjq3Q@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.