Christian Couder <[email protected]> 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 <[email protected]> > --- > 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
