1
0
mirror of https://github.com/git/git synced 2024-06-30 22:54:27 +00:00
git/trailer.h

206 lines
6.4 KiB
C
Raw Normal View History

#ifndef TRAILER_H
#define TRAILER_H
#include "list.h"
#include "strbuf.h"
trailer: make trailer_info struct private In 13211ae23f (trailer: separate public from internal portion of trailer_iterator, 2023-09-09) we moved trailer_info behind an anonymous struct to discourage use by trailer.h API users. However it still left open the possibility of external use of trailer_info itself. Now that there are no external users of trailer_info, we can make this struct private. Make this struct private by putting its definition inside trailer.c. This has two benefits: (1) it makes the surface area of the public facing interface (trailer.h) smaller, and (2) external API users are unable to peer inside this struct (because it is only ever exposed as an opaque pointer). There are a few disadvantages: (A) every time the member of the struct is accessed an extra pointer dereference must be done, and (B) for users of trailer_info outside trailer.c, this struct can no longer be allocated on the stack and may only be allocated on the heap (because its definition is hidden away in trailer.c) and appropriately deallocated by the user, and (C) without good documentation on the API, the opaque struct is hostile to programmers by going opposite to the "Show me your data structures, and I won't usually need your code; it'll be obvious." mantra [2]. (The disadvantages have already been observed in the two preparatory commits that precede this one.) This commit believes that the benefits outweigh the disadvantages for designing APIs, as explained below. Making trailer_info private exposes existing deficiencies in the API. This is because users of this struct had full access to its internals, so there wasn't much need to actually design it to be "complete" in the sense that API users only needed to use what was provided by the API. For example, the location of the trailer block (start/end offsets relative to the start of the input text) was accessible by looking at these struct members directly. Now that the struct is private, we have to expose new API functions to allow clients to access this information (see builtin/interpret-trailers.c). The idea in this commit to hide implementation details behind an "opaque pointer" is also known as the "pimpl" (pointer to implementation) idiom in C++ and is a common pattern in that language (where, for example, abstract classes only have pointers to concrete classes). However, the original inspiration to use this idiom does not come from C++, but instead the book "C Interfaces and Implementations: Techniques for Creating Reusable Software" [1]. This book recommends opaque pointers as a good design principle for designing C libraries, using the term "interface" as the functions defined in *.h (header) files and "implementation" as the corresponding *.c file which define the interfaces. The book says this about opaque pointers: ... clients can manipulate such pointers freely, but they can’t dereference them; that is, they can’t look at the innards of the structure pointed to by them. Only the implementation has that privilege. Opaque pointers hide representation details and help catch errors. In our case, "struct trailer_info" is now hidden from clients, and the ways in which this opaque pointer can be used is limited to the richness of <trailer.h>. In other words, <trailer.h> exclusively controls exactly how "trailer_info" pointers are to be used. [1] Hanson, David R. "C Interfaces and Implementations: Techniques for Creating Reusable Software". Addison Wesley, 1997. p. 22 [2] Raymond, Eric S. "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary". O'Reilly, 1999. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Linus Arver <linus@ucla.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-05-02 04:54:24 +00:00
struct trailer_info;
struct strvec;
enum trailer_where {
WHERE_DEFAULT,
WHERE_END,
WHERE_AFTER,
WHERE_BEFORE,
WHERE_START
};
enum trailer_if_exists {
EXISTS_DEFAULT,
EXISTS_ADD_IF_DIFFERENT_NEIGHBOR,
EXISTS_ADD_IF_DIFFERENT,
EXISTS_ADD,
EXISTS_REPLACE,
EXISTS_DO_NOTHING
};
enum trailer_if_missing {
MISSING_DEFAULT,
MISSING_ADD,
MISSING_DO_NOTHING
};
int trailer_set_where(enum trailer_where *item, const char *value);
int trailer_set_if_exists(enum trailer_if_exists *item, const char *value);
int trailer_set_if_missing(enum trailer_if_missing *item, const char *value);
/*
* A list that represents newly-added trailers, such as those provided
* with the --trailer command line option of git-interpret-trailers.
*/
struct new_trailer_item {
struct list_head list;
const char *text;
enum trailer_where where;
enum trailer_if_exists if_exists;
enum trailer_if_missing if_missing;
};
struct process_trailer_options {
int in_place;
int trim_empty;
int only_trailers;
int only_input;
int unfold;
int no_divider;
int key_only;
int value_only;
const struct strbuf *separator;
const struct strbuf *key_value_separator;
int (*filter)(const struct strbuf *, void *);
void *filter_data;
};
#define PROCESS_TRAILER_OPTIONS_INIT {0}
void parse_trailers_from_config(struct list_head *config_head);
void parse_trailers_from_command_line_args(struct list_head *arg_head,
struct list_head *new_trailer_head);
void process_trailers_lists(struct list_head *head,
struct list_head *arg_head);
/*
* Given some input string "str", return a pointer to an opaque trailer_info
* structure. Also populate the trailer_objects list with parsed trailer
* objects. Internally this calls trailer_info_get() to get the opaque pointer,
* but does some extra work to populate the trailer_objects linked list.
*
* The opaque trailer_info pointer can be used to check the position of the
* trailer block as offsets relative to the beginning of "str" in
* trailer_block_start() and trailer_block_end().
* blank_line_before_trailer_block() returns 1 if there is a blank line just
* before the trailer block. All of these functions are useful for preserving
* the input before and after the trailer block, if we were to write out the
* original input (but with the trailer block itself modified); see
* builtin/interpret-trailers.c for an example.
*
* For iterating through the parsed trailer block (if you don't care about the
* position of the trailer block itself in the context of the larger string text
* from which it was parsed), please see trailer_iterator_init() which uses the
* trailer_info struct internally.
*
* Lastly, callers should call trailer_info_release() when they are done using
* the opaque pointer.
*
* NOTE: Callers should treat both trailer_info and trailer_objects as
* read-only items, because there is some overlap between the two (trailer_info
* has "char **trailers" string array, and trailer_objects will have the same
* data but as a linked list of trailer_item objects). This API does not perform
* any synchronization between the two. In the future we should be able to
* reduce the duplication and use just the linked list.
*/
struct trailer_info *parse_trailers(const struct process_trailer_options *,
const char *str,
struct list_head *trailer_objects);
/*
* Return the offset of the start of the trailer block. That is, 0 is the start
* of the input ("str" in parse_trailers()) and some other positive number
* indicates how many bytes we have to skip over before we get to the beginning
* of the trailer block.
*/
size_t trailer_block_start(struct trailer_info *);
/*
* Return the end of the trailer block, again relative to the start of the
* input.
*/
size_t trailer_block_end(struct trailer_info *);
/*
* Return 1 if the trailer block had an extra newline (blank line) just before
* it.
*/
int blank_line_before_trailer_block(struct trailer_info *);
/*
* Free trailer_info struct.
*/
void trailer_info_release(struct trailer_info *info);
void trailer_config_init(void);
void format_trailers(const struct process_trailer_options *,
struct list_head *trailers,
struct strbuf *out);
void free_trailers(struct list_head *);
/*
* Convenience function to format the trailers from the commit msg "msg" into
* the strbuf "out". Reuses format_trailers() internally.
*/
void format_trailers_from_commit(const struct process_trailer_options *,
trailer: reorder format_trailers_from_commit() parameters Currently there are two functions for formatting trailers in <trailer.h>: void format_trailers(const struct process_trailer_options *, struct list_head *trailers, FILE *outfile); void format_trailers_from_commit(struct strbuf *out, const char *msg, const struct process_trailer_options *opts); and although they are similar enough (even taking the same process_trailer_options struct pointer) they are used quite differently. One might intuitively think that format_trailers_from_commit() builds on top of format_trailers(), but this is not the case. Instead format_trailers_from_commit() calls format_trailer_info() and format_trailers() is never called in that codepath. This is a preparatory refactor to help us deprecate format_trailers() in favor of format_trailer_info() (at which point we can rename the latter to the former). When the deprecation is complete, both format_trailers_from_commit(), and the interpret-trailers builtin will be able to call into the same helper function (instead of format_trailers() and format_trailer_info(), respectively). Unifying the formatters is desirable because it simplifies the API. Reorder parameters for format_trailers_from_commit() to prefer const struct process_trailer_options *opts as the first parameter, because these options are intimately tied to formatting trailers. And take struct strbuf *out last, because it's an "out parameter" (something that the caller wants to use as the output of this function). Similarly, reorder parameters for format_trailer_info(), because later on we will unify the two together. Signed-off-by: Linus Arver <linusa@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-03-01 00:14:42 +00:00
const char *msg,
struct strbuf *out);
/*
* An interface for iterating over the trailers found in a particular commit
* message. Use like:
*
* struct trailer_iterator iter;
* trailer_iterator_init(&iter, msg);
* while (trailer_iterator_advance(&iter))
* ... do something with iter.key and iter.val ...
* trailer_iterator_release(&iter);
*/
struct trailer_iterator {
/*
* Raw line (e.g., "foo: bar baz") before being parsed as a trailer
* key/val pair as part of a trailer block (as the "key" and "val"
* fields below). If a line fails to parse as a trailer, then the "key"
* will be the entire line and "val" will be the empty string.
*/
const char *raw;
struct strbuf key;
struct strbuf val;
/* private */
struct {
struct trailer_info *info;
size_t cur;
} internal;
};
/*
* Initialize "iter" in preparation for walking over the trailers in the commit
* message "msg". The "msg" pointer must remain valid until the iterator is
* released.
*
* After initializing, note that key/val will not yet point to any trailer.
* Call advance() to parse the first one (if any).
*/
void trailer_iterator_init(struct trailer_iterator *iter, const char *msg);
/*
* Advance to the next trailer of the iterator. Returns 0 if there is no such
* trailer, and 1 otherwise. The key and value of the trailer can be
* fetched from the iter->key and iter->value fields (which are valid
* only until the next advance).
*/
int trailer_iterator_advance(struct trailer_iterator *iter);
/*
* Release all resources associated with the trailer iteration.
*/
void trailer_iterator_release(struct trailer_iterator *iter);
/*
* Augment a file to add trailers to it by running git-interpret-trailers.
* This calls run_command() and its return value is the same (i.e. 0 for
* success, various non-zero for other errors). See run-command.h.
*/
int amend_file_with_trailers(const char *path, const struct strvec *trailer_args);
#endif /* TRAILER_H */