Re: [PATCH v7 01/40] apply: move 'struct apply_state' to apply.h

> Christian Couder <christian.couder@gmail.com> writes:
>
>> To libify `git apply` functionality we must make 'struct apply_state'
>> usable outside "builtin/apply.c".
>>
>> Let's do that by creating a new "apply.h" and moving
>> 'struct apply_state' there.
>>
>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>> ---
>>  apply.h         | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  builtin/apply.c |  98 +-----------------------------------------------------
>>  2 files changed, 101 insertions(+), 97 deletions(-)
>>  create mode 100644 apply.h
>>
>> diff --git a/apply.h b/apply.h
>> new file mode 100644
>> index 0000000..9a98eae
>> --- /dev/null
>> +++ b/apply.h
>> @@ -0,0 +1,100 @@
>> +#ifndef APPLY_H
>> +#define APPLY_H
>> +
>> +enum ws_error_action {
>> +     nowarn_ws_error,
>> +     warn_on_ws_error,
>> +     die_on_ws_error,
>> +     correct_ws_error
>> +};
>> +
>> +enum ws_ignore {
>> +     ignore_ws_none,
>> +     ignore_ws_change
>> +};
>> +
>> +/*
>> + * We need to keep track of how symlinks in the preimage are
>> + * manipulated by the patches.  A patch to add a/b/c where a/b
>> + * is a symlink should not be allowed to affect the directory
>> + * the symlink points at, but if the same patch removes a/b,
>> + * it is perfectly fine, as the patch removes a/b to make room
>> + * to create a directory a/b so that a/b/c can be created.
>> + *
>> + * See also "struct string_list symlink_changes" in "struct
>> + * apply_state".
>> + */
>> +#define SYMLINK_GOES_AWAY 01
>> +#define SYMLINK_IN_RESULT 02
>
> Everything below is agreeable, but all the names that are made
> public above by this change do not sound specific enough to "apply".
> I wonder if they should get "apply" somewhere in their names to
> avoid confusion coming from the namespace contamination...