[PATCH 5/5] wt-status: read rebase todolist with strbuf_getline()

[Moritz Neeb <lists@moritzneeb.de>]

    In read_rebase_todolist() every line is, after reading, checked
    for a comment_line_char. After that it is trimmed via strbuf_trim().
    Assuming we do never expect a CR as comment_line_char,
    strbuf_getline_lf() can be safely replaced by its CRLF counterpart.

Signed-off-by: Moritz Neeb <lists@moritzneeb.de>
---

Notes:
    Looking at the code in read_rebase_todolist(), the
    lines are read, checked for a comment_line_char and then trimmed. I
    wonder why the input is not trimmed before checking for this character?
    Is it safe to replace strbuf_getline_lf() by strbuf_getline() anyway?
        The only case I can imagine that could lead to unexpected behaviour then
    would be when someone sets the comment_line_char to CR. How likely is that?
        Why is the trim _after_ checking for the comment char anyway? Should
    something like "   # foobar" not be considered as comment?
        I decided to roll out the patch because I considered it not as a risk to be
    taken seriously, that the comment line char will be '\r'.
        Meta-question: Should something of this discussion be put into the commit?

 wt-status.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wt-status.c b/wt-status.c
index ab4f80d..f053b2f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1076,7 +1076,7 @@ static void read_rebase_todolist(const char *fname, struct string_list *lines)
 	if (!f)
 		die_errno("Could not open file %s for reading",
 			  git_path("%s", fname));
-	while (!strbuf_getline_lf(&line, f)) {
+	while (!strbuf_getline(&line, f)) {
 		if (line.len && line.buf[0] == comment_line_char)
 			continue;
 		strbuf_trim(&line);
-- 
2.4.3