Re: [PATCH 3/4] status: give more information during rebase -i

[Junio C Hamano <gitster@pobox.com>]

Guillaume Pages <guillaume.pages@ensimag.grenoble-inp.fr> writes:

> I felt that was not the right way to do so. What do you think of a
> function like that:
>
> /*
>  * Puts nb_commands commands from filename in lines,
>  * returns the total number of commands in the file
>  * ignores comments and empty lines
>  * lines needs to be at least of size nb_commands
>  * part: 0 get last commands
>  * 	 1 get first commands
>  */
>
> int get_commands(char *filename, int nb_commands, char **lines, int part)
>
> Maybe part is not the best word to choose to take the beginning or the end
> of the file. I also hesitate about adding a parameter to ignore or not the 
> comments.

If I were doing the caller of these two functions, then instead of
adding these specialized helpers, I'd probably structure that caller
this way:

	struct strbuf buf = STRBUF_INIT;
	struct string_list have_done = STRING_LIST_INIT_DUP;
	struct string_list yet_to_do = STRING_LIST_INIT_DUP;
	int have_done_nr, yet_to_do_nr;

	strbuf_read_file(&buf, ".../done", 0);
	stripspace(&buf, 1);
        have_done_nr = string_list_split(&have_done, buf.buf, '\n', -1);
	strbuf_release(&buf);

	strbuf_read_file(&buf, ".../todo", 0);
	stripspace(&buf, 1);
        yet_to_do_nr = string_list_split(&yet_to_do, buf.buf, '\n', -1);
	strbuf_release(&buf);

Then have_done.items[have_done_nr - 1].string would be the last one
that we have replayed, and yet_to_do.items[0].string would be the
next one we are going to replay.