From: Junio C Hamano <gitster@pobox.com>
To: Jiang Xin <worldhello.net@gmail.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
Matthieu Moy <Matthieu.Moy@imag.fr>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH v9 1/9] git-clean: refactor git-clean into two phases
Date: Tue, 14 May 2013 16:27:00 -0700 [thread overview]
Message-ID: <7vvc6ldtx7.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7c551bf22bc45cfcdd62d1baf6300f3f86244312.1368518327.git.worldhello.net@gmail.com> (Jiang Xin's message of "Tue, 14 May 2013 16:45:15 +0800")
Jiang Xin <worldhello.net@gmail.com> writes:
> +/*
> + * Give path as relative to prefix.
> + *
> + * This function is a combination of path_relative (in quote.c) and
> + * relative_path (in path.c)
> + */
> +static const char *path_relative(const char *in, const char *prefix)
> +{
> +...
Hmph. Is it possible to reuse the public one (in path.c) here and
in quote.c, perhaps after enhancing it a bit to serve needs of the
callers of two existing ones and the new callers of this one?
> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> continue; /* Yup, this one exists unmerged */
> }
>
> - /*
> - * we might have removed this as part of earlier
> - * recursive directory removal, so lstat() here could
> - * fail with ENOENT.
> - */
> if (lstat(ent->name, &st))
> continue;
I am guessing that the reason why you removed the comment is because
during this phase there is no way we "might have removed". But if
that is the case, does it still make sense to run lstat() and ignore
errors from the call?
next prev parent reply other threads:[~2013-05-14 23:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 8:45 [PATCH v9 0/9] interactive git-clean Jiang Xin
2013-05-14 8:45 ` [PATCH v9 1/9] git-clean: refactor git-clean into two phases Jiang Xin
2013-05-14 23:27 ` Junio C Hamano [this message]
2013-05-15 0:40 ` Jiang Xin
2013-05-15 15:03 ` Junio C Hamano
2013-05-15 15:07 ` Jiang Xin
2013-05-15 15:18 ` [RFC 0/2] refactor relative_path in path.c Jiang Xin
2013-05-15 18:24 ` Junio C Hamano
2013-05-15 15:18 ` [RFC 1/2] path.c: refactor relative_path(), not only strip prefix Jiang Xin
2013-05-15 15:18 ` [RFC 2/2] quote.c: remove path_relative, use relative_path instead Jiang Xin
2013-05-14 8:45 ` [PATCH v9 2/9] git-clean: add support for -i/--interactive Jiang Xin
2013-05-14 8:45 ` [PATCH v9 3/9] git-clean: show items of del_list in columns Jiang Xin
2013-05-14 8:45 ` [PATCH v9 4/9] git-clean: add colors to interactive git-clean Jiang Xin
2013-05-14 8:45 ` [PATCH v9 5/9] git-clean: use a git-add-interactive compatible UI Jiang Xin
2013-05-14 8:45 ` [PATCH v9 6/9] git-clean: add filter by pattern interactive action Jiang Xin
2013-05-14 8:45 ` [PATCH v9 7/9] git-clean: add select by numbers " Jiang Xin
2013-05-14 8:45 ` [PATCH v9 8/9] git-clean: add ask each " Jiang Xin
2013-05-14 8:45 ` [PATCH v9 9/9] git-clean: add documentation for interactive git-clean Jiang Xin
2013-05-14 23:27 ` [PATCH v9 0/9] " 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=7vvc6ldtx7.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@imag.fr \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
--cc=worldhello.net@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 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).