From: Junio C Hamano <gitster@pobox.com>
To: "Bruce E. Robertson" <bruce.e.robertson@intel.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/1] apply.c: reject patch without --(ex,in)clude and path outside.
Date: Wed, 09 Nov 2011 15:07:15 -0800 [thread overview]
Message-ID: <7vipmsuc7w.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1320878942-9811-1-git-send-email-bruce.e.robertson@intel.com> (Bruce E. Robertson's message of "Wed, 9 Nov 2011 14:49:02 -0800")
"Bruce E. Robertson" <bruce.e.robertson@intel.com> writes:
> From: "Bruce E. Robertson" <bruce.e.robertson@intel.com>
>
> Patches are silently ignored when applied with neither --include nor
> --exclude options when the current working dir is not on patch's
> path. This contravenes the principle of least surprise.
I do not necessarily agree but if you think so perhaps the user should be
told about which paths are rejected. In other words, I think it is wrong
to change the exit code to 1 when you are applying a patch that touches
outside your area, but I think it is not wrong if the program warned about
it.
Does your patch behave like that?
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 84a8a0b..162e2aa 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -3619,6 +3619,7 @@ static struct lock_file lock_file;
>
> static struct string_list limit_by_name;
> static int has_include;
> +static int has_exclude;
> static void add_name_limit(const char *name, int exclude)
> {
> struct string_list_item *it;
> @@ -3717,9 +3718,13 @@ static int apply_patch(int fd, const char *filename, int options)
> listp = &patch->next;
> }
> else {
> - /* perhaps free it a bit better? */
> - free(patch);
> - skipped_patch++;
> + if ( !has_exclude && !has_include ) {
Style; extra SP inside ().
I am not convinced that the logic here is correct, either. If you have
exclude but not include, and the patch records a path outside your area,
the path will be rejected even if it does not match any of the exclude
patterns. Shouldn't you be treating that case exactly the same as the case
without any exclude patterns?
> + patch->rejected = 1;
Doesn't it trigger "errs" to be set in write_out_results()? This patch is
not free()'ed, but it is not on the "list" either. Where does it go, and
how is that unfreed patch used later in the program?
> + } else {
> + /* perhaps free it a bit better? */
> + free(patch);
> + skipped_patch++;
> + }
> }
> offset += nr;
> }
> @@ -3773,6 +3778,7 @@ static int option_parse_exclude(const struct option *opt,
> const char *arg, int unset)
> {
> add_name_limit(arg, 1);
> + has_exclude = 1;
> return 0;
> }
prev parent reply other threads:[~2011-11-09 23:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 22:49 [PATCH 1/1] apply.c: reject patch without --(ex,in)clude and path outside Bruce E. Robertson
2011-11-09 23:07 ` Junio C Hamano [this message]
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=7vipmsuc7w.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bruce.e.robertson@intel.com \
--cc=git@vger.kernel.org \
/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