Joe Perches <joe@xxxxxxxxxxx> writes:
> Add similar capability to --exclude=
>
> Allows selection of files to patch from a
> large patchset.
>
> Signed-off-by: Joe Perches <joe@xxxxxxxxxxx>
Thanks; I don't see anything fundamentally wrong with what this patch
tries to achieve.
> @@ -2996,10 +2996,16 @@ static struct excludes {
> const char *path;
> } *excludes;
>
> +static struct includes {
> + struct includes *next;
> + const char *path;
> +} *includes;
Now this is ugly. You can just add a new variable "*includes" that is of
exactly the same type as existing "*excludes" without introducing a new
type.
You should then find it disturbing that the shared type is still called
"struct excludes" even though it is now used for things you would want to
include. You are right. You can then either rename it to a more neutral
name, or (even better) use an existing type, such as "string_list".
Which would mean that this patch should be done as two patches:
[1/2] builtin-apply.c: Use "string_list" for "--excludes".
[2/2] builtin-apply.c: Add "--includes" option.
The first will be a preparatory step that does not change any externally
visible behaviour. The only thing it will do is to change the type of
"excludes" to "struct string_list", to update the option parser to use
string_list_append() to add to it, and to update the way "use_patch()" to
iterate over the items in the exclude list.
The second will add a new "includes" variable, and do the moral equivalent
of what your patch did.
The first patch most likely should introduce a new helper function:
int string_list_has_match(struct string_list *s, const char *path);
so that the update to "use_patch()" that needs to be done in the second
patch can just pass a different string_list to implement the additional
check.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
