summaryrefslogtreecommitdiff
path: root/strbuf.h
AgeCommit message (Collapse)AuthorFilesLines
2016-10-10link_alt_odb_entry: handle normalize_path errorsLibravatar Jeff King1-0/+8
When we add a new alternate to the list, we try to normalize out any redundant "..", etc. However, we do not look at the return value of normalize_path_copy(), and will happily continue with a path that could not be normalized. Worse, the normalizing process is done in-place, so we are left with whatever half-finished working state the normalizing function was in. Fortunately, this cannot cause us to read past the end of our buffer, as that working state will always leave the NUL from the original path in place. And we do tend to notice problems when we check is_directory() on the path. But you can see the nonsense that we feed to is_directory with an entry like: this/../../is/../../way/../../too/../../deep/../../to/../../resolve in your objects/info/alternates, which yields: error: object directory /to/e/deep/too/way//ects/this/../../is/../../way/../../too/../../deep/../../to/../../resolve does not exist; check .git/objects/info/alternates. We can easily fix this just by checking the return value. But that makes it hard to generate a good error message, since we're normalizing in-place and our input value has been overwritten by cruft. Instead, let's provide a strbuf helper that does an in-place normalize, but restores the original contents on error. This uses a second buffer under the hood, which is slightly less efficient, but this is not a performance-critical code path. The strbuf helper can also properly set the "len" parameter of the strbuf before returning. Just doing: normalize_path_copy(buf.buf, buf.buf); will shorten the string, but leave buf.len at the original length. That may be confusing to later code which uses the strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'rs/use-strbuf-addbuf'Libravatar Junio C Hamano1-5/+1
Code cleanup. * rs/use-strbuf-addbuf: strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf() use strbuf_addbuf() for appending a strbuf to another
2016-07-22strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()Libravatar René Scharfe1-5/+1
Implement strbuf_addbuf() as a normal function in order to avoid calling strbuf_grow() twice, with the second callinside strbud_add() being a no-op. This is slightly faster and also reduces the text size a bit. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'pb/strbuf-read-file-doc'Libravatar Junio C Hamano1-0/+2
* pb/strbuf-read-file-doc: strbuf: describe the return value of strbuf_read_file
2016-06-14strbuf: describe the return value of strbuf_read_fileLibravatar Pranit Bauva1-0/+2
Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Merge branch 'sb/submodule-parallel-update'Libravatar Junio C Hamano1-0/+6
A major part of "git submodule update" has been ported to C to take advantage of the recently added framework to run download tasks in parallel. * sb/submodule-parallel-update: clone: allow an explicit argument for parallel submodule clones submodule update: expose parallelism to the user submodule helper: remove double 'fatal: ' prefix git submodule update: have a dedicated helper for cloning run_processes_parallel: rename parameters for the callbacks run_processes_parallel: treat output of children as byte array submodule update: direct error message to stderr fetching submodules: respect `submodule.fetchJobs` config option submodule-config: drop check against NULL submodule-config: keep update strategy around
2016-03-01run_processes_parallel: treat output of children as byte arrayLibravatar Stefan Beller1-0/+6
We do not want the output to be interrupted by a NUL byte, so we cannot use raw fputs. Introduce strbuf_write to avoid having long arguments in run-command.c. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28Merge branch 'jc/strbuf-getline'Libravatar Junio C Hamano1-6/+23
The preliminary clean-up for jc/peace-with-crlf topic. * jc/strbuf-getline: strbuf: give strbuf_getline() to the "most text friendly" variant checkout-index: there are only two possible line terminations update-index: there are only two possible line terminations check-ignore: there are only two possible line terminations check-attr: there are only two possible line terminations mktree: there are only two possible line terminations strbuf: introduce strbuf_getline_{lf,nul}() strbuf: make strbuf_getline_crlf() global strbuf: miniscule style fix
2016-01-15strbuf: give strbuf_getline() to the "most text friendly" variantLibravatar Junio C Hamano1-12/+10
Now there is no direct caller to strbuf_getline(), we can demote it to file-scope static that is private to strbuf.c and rename it to strbuf_getdelim(). Rename strbuf_getline_crlf(), which is designed to be the most "text friendly" variant, and allow it to take over this simplest name, strbuf_getline(), so we can add more uses of it without having to type _crlf over and over again in the coming steps. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-15strbuf: introduce strbuf_getline_{lf,nul}()Libravatar Junio C Hamano1-3/+15
The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14strbuf: make strbuf_getline_crlf() globalLibravatar Junio C Hamano1-0/+7
Often we read "text" files that are supplied by the end user (e.g. commit log message that was edited with $GIT_EDITOR upon 'git commit -e'), and in some environments lines in a text file are terminated with CRLF. Existing strbuf_getline() knows to read a single line and then strip the terminating byte from the result, but it is handy to have a version that is more tailored for a "text" input that takes both '\n' and '\r\n' as line terminator (aka <newline> in POSIX lingo) and returns the body of the line after stripping <newline>. Recently reimplemented "git am" uses such a function implemented privately; move it to strbuf.[ch] and make it available for others. Note that we do not blindly replace calls to strbuf_getline() that uses LF as the line terminator with calls to strbuf_getline_crlf() and this is very much deliberate. Some callers may want to treat an incoming line that ends with CR (and terminated with LF) to have a payload that includes the final CR, and such a blind replacement will result in misconversion when done without code audit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-16strbuf: add strbuf_read_once to read without blockingLibravatar Stefan Beller1-0/+8
The new call will read from a file descriptor into a strbuf once. The underlying call xread is just run once. xread only reattempts reading in case of EINTR, which makes it suitable to use for a nonblocking read. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-26Merge branch 'tk/stripspace'Libravatar Junio C Hamano1-1/+10
The internal stripspace() function has been moved to where it logically belongs to, i.e. strbuf API, and the command line parser of "git stripspace" has been updated to use the parse_options API. * tk/stripspace: stripspace: use parse-options for command-line parsing strbuf: make stripspace() part of strbuf
2015-10-16strbuf: make stripspace() part of strbufLibravatar Tobias Klauser1-1/+10
This function is also used in other builtins than stripspace, so it makes sense to have it in a more generic place. Since it operates on an strbuf and the function is declared in strbuf.h, move it to strbuf.c and add the corresponding prefix to its name, just like other API functions in the strbuf_* family. Also switch all current users of stripspace() to the new function name and keep a temporary wrapper inline function for any topic branches still using stripspace(). Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25add reentrant variants of sha1_to_hex and find_unique_abbrevLibravatar Jeff King1-0/+8
The sha1_to_hex and find_unique_abbrev functions always write into reusable static buffers. There are a few problems with this: - future calls overwrite our result. This is especially annoying with find_unique_abbrev, which does not have a ring of buffers, so you cannot even printf() a result that has two abbreviated sha1s. - if you want to put the result into another buffer, we often strcpy, which looks suspicious when auditing for overflows. This patch introduces sha1_to_hex_r and find_unique_abbrev_r, which write into a user-provided buffer. Of course this is just punting on the overflow-auditing, as the buffer obviously needs to be GIT_SHA1_HEXSZ + 1 bytes. But it is much easier to audit, since that is a well-known size. We retain the non-reentrant forms, which just become thin wrappers around the reentrant ones. This patch also adds a strbuf variant of find_unique_abbrev, which will be handy in later patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25strbuf: make strbuf_complete_line more genericLibravatar Jeff King1-2/+13
The strbuf_complete_line function makes sure that a buffer ends in a newline. But we may want to do this for any character (e.g., "/" on the end of a path). Let's factor out a generic version, and keep strbuf_complete_line as a thin wrapper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'jk/date-mode-format'Libravatar Junio C Hamano1-0/+5
Teach "git log" and friends a new "--date=format:..." option to format timestamps using system's strftime(3). * jk/date-mode-format: strbuf: make strbuf_addftime more robust introduce "format" date-mode convert "enum date_mode" into a struct show-branch: use DATE_RELATIVE instead of magic number
2015-07-13Merge branch 'mh/strbuf-read-file-returns-ssize-t'Libravatar Junio C Hamano1-1/+1
Avoid possible ssize_t to int truncation. * mh/strbuf-read-file-returns-ssize-t: strbuf: strbuf_read_file() should return ssize_t
2015-07-03strbuf: strbuf_read_file() should return ssize_tLibravatar Michael Haggerty1-1/+1
It is currently declared to return int, which could overflow for large files. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-29introduce "format" date-modeLibravatar Jeff King1-0/+5
This feeds the format directly to strftime. Besides being a little more flexible, the main advantage is that your system strftime may know more about your locale's preferred format (e.g., how to spell the days of the week). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-16strbuf_addch: avoid calling strbuf_growLibravatar Jeff King1-1/+2
We mark strbuf_addch as inline, because we expect it may be called from a tight loop. However, the first thing it does is call the non-inline strbuf_grow(), which can handle arbitrary-sized growth. Since we know that we only need a single character, we can use the inline strbuf_avail() to quickly check whether we need to grow at all. Our check is redundant when we do call strbuf_grow(), but that's OK. The common case is that we avoid calling it at all, and we have made that case faster. On a silly pathological case: perl -le ' print "[core]"; print "key$_ = value$_" for (1..1000000) ' >input git config -f input core.key1 this dropped the time to run git-config from: real 0m0.159s user 0m0.152s sys 0m0.004s to: real 0m0.140s user 0m0.136s sys 0m0.004s for a savings of 12%. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: group documentation for trim functionsLibravatar Jeff King1-10/+2
The relationship between these makes more sense if you read them as a group, which can help people who are looking for the right function. Let's give them a single comment. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: drop boilerplate descriptions of strbuf_split_*Libravatar Jeff King1-12/+5
The description of strbuf_split_buf says most of what needs to be said for all of the split variants that take strings, raw memory, etc. We have a boilerplate comment above each that points to the first. This boilerplate ends up making it harder to read, because it spaces out the functions, which could otherwise be read as a group. Let's drop the boilerplate completely, and mention the variants in the top comment. This is perhaps slightly worse for a hypothetical system which pulls the documentation for each function out of the comment immediately preceding it. But such a system does not yet exist, and anyway, the end result of extracting the boilerplate comments would not lead to a very easy-to-read result. We would do better in the long run to teach the extraction system about groups of related functions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: reorganize api function grouping headersLibravatar Jeff King1-9/+8
The original API doc had something like: Functions --------- * Life cycle ... some life-cycle functions ... * Related to the contents of the buffer ... functions related to contents .... etc This grouping can be hard to read in the comment sources, given the "*" in the comment lines, and the amount of text between each section. Instead, let's make a flat list of groupings, and underline each as a section header. That makes them stand out, and eliminates the weird half-phrase of "Related to...". Like: Functions related to the contents of the buffer ----------------------------------------------- Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: format asciidoc code blocks as 4-space indentLibravatar Jeff King1-7/+4
This is much easier to read when the whole thing is stuffed inside a comment block. And there is precedent for this convention in markdown (and just in general ascii text). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: drop asciidoc list formatting from API docsLibravatar Jeff King1-37/+37
Using a hanging indent is much more readable. This means we won't format as asciidoc anymore, but since we don't have a working system for extracting these comments anyway, it's probably more important to just make the source readable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: unify documentation comments beginningsLibravatar Stefan Beller1-7/+7
The prior patch uses "/**" to denote "documentation" comments that we pulled from api-strbuf.txt. Let's use a consistent style for similar comments that were already in strbuf.h. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16strbuf.h: integrate api-strbuf.txt documentationLibravatar Jeff King1-67/+390
Some of strbuf is documented as comments above functions, and some is separate in Documentation/technical/api-strbuf.txt. This makes it annoying to find the appropriate documentation. We'd rather have it all in one place, which means all in the text document, or all in the header. Let's choose the header as that place. Even though the formatting is not quite as pretty, this keeps the documentation close to the related code. The hope is that this makes it easier to find what you want (human-readable comments are right next to the C declarations), and easier for writers to keep the documentation up to date. This is more or less a straight import of the text from api-strbuf.txt into C comments, complete with asciidoc formatting. The exceptions are: 1. All comments created in this way are started with "/**" to indicate they are part of the API documentation. This may help later with extracting the text to pretty-print it. 2. Function descriptions do not repeat the function name, as it is available in the context directly below. So: `strbuf_add`:: Add data of given length to the buffer. from api-strbuf.txt becomes: /** * Add data of given length to the buffer. */ void strbuf_add(struct strbuf *sb, const void *, size_t); As a result, any block-continuation required in asciidoc for that list item was dropped in favor of straight blank-line paragraph (since it is not necessary when we are not in a list item). 3. There is minor re-wording to integrate existing comments and api-strbuf text. In each case, I took whichever version was more descriptive, and eliminated any redundancies. In one case, for strbuf_addstr, the api documentation gave its inline definition; I eliminated this as redundant with the actual definition, which can be seen directly below the comment. 4. The functions in the header file are re-ordered to match the ordering of the API documentation, under the assumption that more thought went into the grouping there. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-19Merge branch 'rs/export-strbuf-addchars'Libravatar Junio C Hamano1-0/+1
Code clean-up. * rs/export-strbuf-addchars: strbuf: use strbuf_addchars() for adding a char multiple times strbuf: export strbuf_addchars()
2014-09-08strbuf: export strbuf_addchars()Libravatar René Scharfe1-0/+1
Move strbuf_addchars() to strbuf.c, where it belongs, and make it available for other callers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-02Merge branch 'rs/strbuf-getcwd'Libravatar Junio C Hamano1-0/+3
Reduce the use of fixed sized buffer passed to getcwd() calls by introducing xgetcwd() helper. * rs/strbuf-getcwd: use strbuf_add_absolute_path() to add absolute paths abspath: convert absolute_path() to strbuf use xgetcwd() to set $GIT_DIR use xgetcwd() to get the current directory or die wrapper: add xgetcwd() abspath: convert real_path_internal() to strbuf abspath: use strbuf_getcwd() to remember original working directory setup: convert setup_git_directory_gently_1 et al. to strbuf unix-sockets: use strbuf_getcwd() strbuf: add strbuf_getcwd()
2014-08-26abspath: convert absolute_path() to strbufLibravatar René Scharfe1-0/+2
Move most of the code of absolute_path() into the new function strbuf_add_absolute_path() and in the process transform it to use struct strbuf and xgetcwd() instead of a PATH_MAX-sized buffer, which can be too small on some file systems. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-28strbuf: add strbuf_getcwd()Libravatar René Scharfe1-0/+1
Add strbuf_getcwd(), which puts the current working directory into a strbuf. Because it doesn't use a fixed-size buffer it supports arbitrarily long paths, provided the platform's getcwd() does as well. At least on Linux and FreeBSD it handles paths longer than PATH_MAX just fine. Suggested-by: Karsten Blees <karsten.blees@gmail.com> Helped-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16Merge branch 'jk/strip-suffix'Libravatar Junio C Hamano1-0/+9
* jk/strip-suffix: prepare_packed_git_one: refactor duplicate-pack check verify-pack: use strbuf_strip_suffix strbuf: implement strbuf_strip_suffix index-pack: use strip_suffix to avoid magic numbers use strip_suffix instead of ends_with in simple cases replace has_extension with ends_with implement ends_with via strip_suffix add strip_suffix function sha1_file: replace PATH_MAX buffer with strbuf in prepare_packed_git_one()
2014-06-30strbuf: implement strbuf_strip_suffixLibravatar Jeff King1-0/+9
You can almost get away with just calling "strip_suffix_mem" on a strbuf's buf and len fields. But we also need to move the NUL-terminator to satisfy strbuf's invariants. Let's provide a convenience wrapper that handles this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19strbuf: add xstrfmt helperLibravatar Jeff King1-0/+9
You can use a strbuf to build up a string from parts, and then detach it. In the general case, you might use multiple strbuf_add* functions to do the building. However, in many cases, a single strbuf_addf is sufficient, and we end up with: struct strbuf buf = STRBUF_INIT; ... strbuf_addf(&buf, fmt, some, args); str = strbuf_detach(&buf, NULL); We can make this much more readable (and avoid introducing an extra variable, which can clutter the code) by introducing a convenience function: str = xstrfmt(fmt, some, args); Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-16Merge branch 'jk/http-errors'Libravatar Junio C Hamano1-0/+1
Propagate the error messages from the webserver better to the client coming over the HTTP transport. * jk/http-errors: http: default text charset to iso-8859-1 remote-curl: reencode http error messages strbuf: add strbuf_reencode helper http: optionally extract charset parameter from content-type http: extract type/subtype portion of content-type t5550: test display of remote http error messages t/lib-httpd: use write_script to copy CGI scripts test-lib: preserve GIT_CURL_VERBOSE from the environment
2014-06-16Merge branch 'jk/strbuf-tolower'Libravatar Junio C Hamano1-0/+1
* jk/strbuf-tolower: strbuf: add strbuf_tolower function
2014-06-16Merge branch 'jk/daemon-tolower'Libravatar Junio C Hamano1-0/+2
* jk/daemon-tolower: daemon/config: factor out duplicate xstrdup_tolower
2014-05-27strbuf: add strbuf_reencode helperLibravatar Jeff King1-0/+1
This is a convenience wrapper around `reencode_string_len` and `strbuf_attach`. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-23strbuf: add strbuf_tolower functionLibravatar Jeff King1-0/+1
This is a convenience wrapper to call tolower on each character of the string. This makes config's lowercase() function obsolete, though note that because we have a strbuf, we are careful to operate over the whole strbuf, rather than assuming that a NUL is the end-of-string. We could continue to offer a pure-string lowercase, but there would be no callers (in most pure-string cases, we actually duplicate and lowercase the duplicate, for which we have the xstrdup_tolower wrapper). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-23daemon/config: factor out duplicate xstrdup_tolowerLibravatar Jeff King1-0/+2
We have two implementations of the same function; let's drop that to one. We take the name from daemon.c, but the implementation (which is just slightly more efficient) from the config code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-03strbuf: style fix -- top opening bracket on a separate lineLibravatar Nguyễn Thái Ngọc Duy1-6/+12
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-10strbuf: create strbuf_humanise_bytes() to show byte sizesLibravatar Antoine Pelisse1-0/+1
Humanization of downloaded size is done in the same function as text formatting in 'process.c'. The code cannot be reused easily elsewhere. Separate text formatting from size simplification and make the function public in strbuf so that it can easily be used by other callers. We now can use strbuf_humanise_bytes() for both downloaded size and download speed calculation. One of the drawbacks is that speed will now look like this when download is stalled: "0 bytes/s" instead of "0 KiB/s". Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16Allow custom "comment char"Libravatar Junio C Hamano1-0/+4
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05Merge branch 'mh/unify-xml-in-imap-send-and-http-push'Libravatar Junio C Hamano1-0/+6
Update imap-send to reuse xml quoting code from http-push codepath, clean up some code, and fix a small bug. * mh/unify-xml-in-imap-send-and-http-push: wrap_in_html(): process message in bulk rather than line-by-line wrap_in_html(): use strbuf_addstr_xml_quoted() imap-send: change msg_data from storing (ptr, len) to storing strbuf imap-send: correctly report errors reading from stdin imap-send: store all_msgs as a strbuf lf_to_crlf(): NUL-terminate msg_data::data xml_entities(): use function strbuf_addstr_xml_quoted() Add new function strbuf_add_xml_quoted()
2012-11-26Add new function strbuf_add_xml_quoted()Libravatar Michael Haggerty1-0/+6
Substantially the same code is present in http-push.c and imap-send.c, so make a library function out of it. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-04strbuf_split*(): document functionsLibravatar Michael Haggerty1-0/+33
Document strbuf_split_buf(), strbuf_split_str(), strbuf_split_max(), strbuf_split(), and strbuf_list_free() in the header file and in api-strbuf.txt. (These functions were previously completely undocumented.) Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-11-04strbuf_split*(): rename "delim" parameter to "terminator"Libravatar Michael Haggerty1-7/+8
The word "delimiter" suggests that the argument separates the substrings, whereas in fact (1) the delimiter characters are included in the output, and (2) if the input string ends with the delimiter, then the output does not include a final empty string. So rename the "delim" arguments of the strbuf_split() family of functions to "terminator", which is more suggestive of how it is used. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-09-15strbuf.c: mark a private file-scope symbol as staticLibravatar Junio C Hamano1-4/+0
Also remove an unused function. Signed-off-by: Junio C Hamano <gitster@pobox.com>