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...
--
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