On Tue, Jun 14, 2016 at 12:49 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Christian Couder <christian.couder@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>> ---
>> 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...
Yeah, I will add "apply" in the names.
Thanks,
Christian.
--
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