Hi,
Johannes Schindelin wrote:
> While regular commit histories hardly win comprehensibility in general
> if they merge more than twenty-two branches in one go, it is not Git's
> business to limit grafts in such a way.
Fun. :) Makes sense.
[...]
> ---
> builtin/blame.c | 8 ++++----
> commit.c | 10 +++++-----
> 2 files changed, 9 insertions(+), 9 deletions(-)
Is this easy to reproduce so some interested but lazy person could
write a test?
[...]
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1804,17 +1804,17 @@ static int prepare_lines(struct scoreboard *sb)
> static int read_ancestry(const char *graft_file)
> {
> FILE *fp = fopen(graft_file, "r");
> - char buf[1024];
> + struct strbuf buf = STRBUF_INIT;
> if (!fp)
> return -1;
> - while (fgets(buf, sizeof(buf), fp)) {
> + while (!strbuf_getwholeline(&buf, fp, '\n')) {
If there is no newline at EOF, this will skip the last line, while the
old behavior was to pay attention to it. I haven't thought through
whether that's a good or bad change. Maybe it should just be
documented?
[...]
> --- a/commit.c
> +++ b/commit.c
> @@ -196,19 +196,19 @@ static int read_graft_file(const char *graft_file)
[...]
> - while (fgets(buf, sizeof(buf), fp)) {
> + while (!strbuf_getwholeline(&buf, fp, '\n')) {
Likewise.
The rest of the patch looks good.
Merry christmas,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
