Re: [PATCH] Remove the line length limit for graft files
Jonathan Nieder writes: > Johannes Schindelin wrote: >> On Fri, 27 Dec 2013, Jonathan Nieder wrote: > >>> Is this easy to reproduce so some interested but lazy person could >>> write a test? >> >> Yep. Make 25 orphan commits, add a graft line to make the first a merge of >> the rest. > > Thanks. Here's a pair of tests doing that. > > Signed-off-by: Jonathan Nieder > --- > t/annotate-tests.sh | 21 + > t/t6101-rev-parse-parents.sh | 16 +++- > 2 files changed, 36 insertions(+), 1 deletion(-) Makes sense. Thanks, both. Small lint-picking like this change to perfect the system, as opposed to earth-shattering new shinies, tend to often get neglected but are very much appreciated. > diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh > index c9d105d..304c7b7 100644 > --- a/t/annotate-tests.sh > +++ b/t/annotate-tests.sh > @@ -116,6 +116,27 @@ test_expect_success 'blame evil merge' ' > check_count A 2 B 1 B1 2 B2 1 "A U Thor" 1 > ' > > +test_expect_success 'blame huge graft' ' > + test_when_finished "git checkout branch2" && > + test_when_finished "rm -f .git/info/grafts" && > + graft= && > + for i in 0 1 2 > + do > + for j in 0 1 2 3 4 5 6 7 8 9 > + do > + git checkout --orphan "$i$j" && > + printf "%s\n" "$i" "$j" >file && > + test_tick && > + GIT_AUTHOR_NAME=$i$j GIT_AUTHOR_EMAIL=$i$j...@test.git \ > + git commit -a -m "$i$j" && > + commit=$(git rev-parse --verify HEAD) && > + graft="$graft$commit " > + done > + done && > + printf "%s " $graft >.git/info/grafts && > + check_count -h 00 01 1 10 1 > +' > + > test_expect_success 'setup incomplete line' ' > echo "incomplete" | tr -d "\\012" >>file && > GIT_AUTHOR_NAME="C" GIT_AUTHOR_EMAIL="c...@test.git" \ > diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh > index 7ea14ce..10b1452 100755 > --- a/t/t6101-rev-parse-parents.sh > +++ b/t/t6101-rev-parse-parents.sh > @@ -20,7 +20,17 @@ test_expect_success 'setup' ' > test_commit start2 && > git checkout master && > git merge -m next start2 && > - test_commit final > + test_commit final && > + > + test_seq 40 | > + while read i > + do > + git checkout --orphan "b$i" && > + test_tick && > + git commit --allow-empty -m "$i" && > + commit=$(git rev-parse --verify HEAD) && > + printf "$commit " >>.git/info/grafts > + done > ' > > test_expect_success 'start is valid' ' > @@ -79,6 +89,10 @@ test_expect_success 'final^1^! = final^1 ^final^1^1 > ^final^1^2' ' > test_cmp expect actual > ' > > +test_expect_success 'large graft octopus' ' > + test_cmp_rev_output b31 "git rev-parse --verify b1^30" > +' > + > test_expect_success 'repack for next test' ' > git repack -a -d > ' > -- > 1.8.5.1 > > -- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Hi Jonathan, On Fri, 27 Dec 2013, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > On Fri, 27 Dec 2013, Jonathan Nieder wrote: > > >> Is this easy to reproduce so some interested but lazy person could > >> write a test? > > > > Yep. Make 25 orphan commits, add a graft line to make the first a merge of > > the rest. > > Thanks. Here's a pair of tests doing that. Thank you very much! > + for i in 0 1 2 > + do > + for j in 0 1 2 3 4 5 6 7 8 9 > + do for the record, I usually prefer i=0 while test $i -t 30 do ... i=$(($i+1)) done but your code is just as good! Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Hi Jonathan, On Fri, 27 Dec 2013, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > it returns EOF only if ch == EOF *and* sb->len == 0, i.e. if no characters > > have been read before hitting EOF. > > Yep. api-strbuf.txt even says so. I never bothered to look ;-) > Sorry for the nonsense. Nope, no nonsense at all. I actually had a look only after your review, and it definitely makes sense to double-check. > For what it's worth, > Reviewed-by: Jonathan Nieder It is worth a lot. Believe me, I know just how thankless a task reviewing is, and instead of getting praise for it, you even get abused by contributors who would rather self-review their code for fear of having a twist in their knockers pointed out publicly. Your review makes the code better, even if it does not result in code changes all the time: it increases the confidence that the code is good. Thank you, Jonathan! Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Johannes Schindelin wrote: > On Fri, 27 Dec 2013, Jonathan Nieder wrote: >> Is this easy to reproduce so some interested but lazy person could >> write a test? > > Yep. Make 25 orphan commits, add a graft line to make the first a merge of > the rest. Thanks. Here's a pair of tests doing that. Signed-off-by: Jonathan Nieder --- t/annotate-tests.sh | 21 + t/t6101-rev-parse-parents.sh | 16 +++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh index c9d105d..304c7b7 100644 --- a/t/annotate-tests.sh +++ b/t/annotate-tests.sh @@ -116,6 +116,27 @@ test_expect_success 'blame evil merge' ' check_count A 2 B 1 B1 2 B2 1 "A U Thor" 1 ' +test_expect_success 'blame huge graft' ' + test_when_finished "git checkout branch2" && + test_when_finished "rm -f .git/info/grafts" && + graft= && + for i in 0 1 2 + do + for j in 0 1 2 3 4 5 6 7 8 9 + do + git checkout --orphan "$i$j" && + printf "%s\n" "$i" "$j" >file && + test_tick && + GIT_AUTHOR_NAME=$i$j GIT_AUTHOR_EMAIL=$i$j...@test.git \ + git commit -a -m "$i$j" && + commit=$(git rev-parse --verify HEAD) && + graft="$graft$commit " + done + done && + printf "%s " $graft >.git/info/grafts && + check_count -h 00 01 1 10 1 +' + test_expect_success 'setup incomplete line' ' echo "incomplete" | tr -d "\\012" >>file && GIT_AUTHOR_NAME="C" GIT_AUTHOR_EMAIL="c...@test.git" \ diff --git a/t/t6101-rev-parse-parents.sh b/t/t6101-rev-parse-parents.sh index 7ea14ce..10b1452 100755 --- a/t/t6101-rev-parse-parents.sh +++ b/t/t6101-rev-parse-parents.sh @@ -20,7 +20,17 @@ test_expect_success 'setup' ' test_commit start2 && git checkout master && git merge -m next start2 && - test_commit final + test_commit final && + + test_seq 40 | + while read i + do + git checkout --orphan "b$i" && + test_tick && + git commit --allow-empty -m "$i" && + commit=$(git rev-parse --verify HEAD) && + printf "$commit " >>.git/info/grafts + done ' test_expect_success 'start is valid' ' @@ -79,6 +89,10 @@ test_expect_success 'final^1^! = final^1 ^final^1^1 ^final^1^2' ' test_cmp expect actual ' +test_expect_success 'large graft octopus' ' + test_cmp_rev_output b31 "git rev-parse --verify b1^30" +' + test_expect_success 'repack for next test' ' git repack -a -d ' -- 1.8.5.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Johannes Schindelin wrote: > it returns EOF only if ch == EOF *and* sb->len == 0, i.e. if no characters > have been read before hitting EOF. Yep. api-strbuf.txt even says so. Sorry for the nonsense. For what it's worth, Reviewed-by: Jonathan Nieder -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Johannes Schindelin writes:
> Support for grafts predates Git's strbuf, and hence it is understandable
> that there was a hard-coded line length limit of 1023 characters (which
> was chosen a bit awkwardly, given that it is *exactly* one byte short of
> aligning with the 41 bytes occupied by a commit name and the following
> space or new-line character).
>
> 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.
>
> In this particular developer's case, the use case that requires
> substantially longer graft lines to be supported is the visualization of
> the commits' order implied by their changes: commits are considered to
> have an implicit relationship iff exchanging them in an interactive
> rebase would result in merge conflicts.
>
> Thusly implied branches tend to be very shallow in general, and the
> resulting thicket of implied branches is usually very wide; It is
> actually quite common that *most* of the commits in a topic branch have
> not even one implied parent, so that a final merge commit has about as
> many implied parents as there are commits in said branch.
>
> Signed-off-by: Johannes Schindelin
> ---
> builtin/blame.c | 8
> commit.c| 10 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
Makes sense. It is in line with the spirit of ef98c5cafb3e
(commit-tree: lift completely arbitrary limit of 16 parents,
2008-06-27), too ;-)
Thanks, will queue.
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 1407ae7..9047b6e 100644
> --- 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')) {
> /* The format is just "Commit Parent1 Parent2 ...\n" */
> - int len = strlen(buf);
> - struct commit_graft *graft = read_graft_line(buf, len);
> + struct commit_graft *graft = read_graft_line(buf.buf, buf.len);
> if (graft)
> register_commit_graft(graft, 0);
> }
> fclose(fp);
> + strbuf_release(&buf);
> return 0;
> }
>
> diff --git a/commit.c b/commit.c
> index de16a3c..57ebea2 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -196,19 +196,19 @@ bad_graft_data:
> static int read_graft_file(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')) {
> /* The format is just "Commit Parent1 Parent2 ...\n" */
> - int len = strlen(buf);
> - struct commit_graft *graft = read_graft_line(buf, len);
> + struct commit_graft *graft = read_graft_line(buf.buf, buf.len);
> if (!graft)
> continue;
> if (register_commit_graft(graft, 1))
> - error("duplicate graft data: %s", buf);
> + error("duplicate graft data: %s", buf.buf);
> }
> fclose(fp);
> + strbuf_release(&buf);
> return 0;
> }
>
> --
> 1.8.4.msysgit.0.1109.g3c58b16
>
> --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
Hi,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>
> [...]
> > ---
> > 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?
Yep. Make 25 orphan commits, add a graft line to make the first a merge of
the rest.
> > --- 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?
The way I read
int strbuf_getwholeline(struct strbuf *sb, FILE *fp, int term)
{
int ch;
if (feof(fp))
return EOF;
strbuf_reset(sb);
while ((ch = fgetc(fp)) != EOF) {
strbuf_grow(sb, 1);
sb->buf[sb->len++] = ch;
if (ch == term)
break;
}
if (ch == EOF && sb->len == 0)
return EOF;
sb->buf[sb->len] = '\0';
return 0;
}
it returns EOF only if ch == EOF *and* sb->len == 0, i.e. if no characters
have been read before hitting EOF.
In other words, strbuf_getwholeline() -- despite requiring an explicit
terminating character argument -- does not require the last line to end
with that terminating character.
A quick test (in my case, because I am lazy, modifying test-mergesort.c to
output the lines that were read by strbuf_getwholeline()) also confirms my
suspicion.
Or maybe I missed something?
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the line length limit for graft files
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
