Jeff King <peff@xxxxxxxx> writes: > diff --git a/strbuf.h b/strbuf.h > index 1883494..93a50da 100644 > --- a/strbuf.h > +++ b/strbuf.h > @@ -1,6 +1,8 @@ > #ifndef STRBUF_H > #define STRBUF_H > > +struct child_process; > + > /** > * strbuf's are meant to be used with all the usual C string and memory > * APIs. Given that the length of the buffer is known, it's often better to > @@ -373,6 +375,14 @@ extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint); > extern int strbuf_readlink(struct strbuf *sb, const char *path, size_t hint); > > /** > + * Execute the given command, capturing its stdout in the given strbuf. > + * Returns -1 if starting the command fails or reading fails, and otherwise > + * returns the exit code of the command. The output collected in the > + * buffer is kept even if the command returns a non-zero exit. > + */ > +int strbuf_read_cmd(struct strbuf *sb, struct child_process *cmd, size_t hint); > + > +/** > * Read a line from a FILE *, overwriting the existing contents > * of the strbuf. The second argument specifies the line > * terminator character, typically `'\n'`. It is an unfortunate tangent that this is a bugfix that may want to go to 'maint' and older, but our earlier jk/strbuf-doc-to-header topic introduces an unnecessary merge conflicts. I've wiggled this part and moved the doc elsewhere, only to remove that in the merge, which may not be optimal from the point of view of what I have to do when merging this topic down from pu to next to master to maint, but I do not see a good way around it. Thanks. The whole series looks very sensible. -- 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