rev-list: add --count to usage guide
PATCH 1/1 rev-list: add --count to usage guide
--count should be mentioned in the usage guide, this updates code and documentation.
--- Documentation/git-rev-list.txt | 1 + builtin/rev-list.c | 1 + 2 files changed, 2 insertions(+)
Documentation/git-rev-list.txt +1 -0
@@ -56,6 +56,7 @@ SYNOPSIS [ --reverse ] [ --walk-reflogs ] [ --no-walk ] [ --do-walk ] + [ --count ] [ --use-bitmap-index ] <commit>... [ \-- <paths>... ]
builtin/rev-list.c +1 -0
@@ -42,6 +42,7 @@ static const char rev_list_usage[] =" --abbrev=<n> | --no-abbrev\n" " --abbrev-commit\n" " --left-right\n" +" --count\n" " special purpose:\n" " --bisect\n" " --bisect-vars\n"
Signature · 1 line
1.9.1
Quoted 5 lines · Lawrence Siebert
--count should be mentioned in the usage guide, this updates code and documentation.
Signed-off-by Lawrence Siebert <[email protected]>---
Sounds good. While at it, perhaps add a mention (perhaps by creating a BUGS section at the end of the file) that --count with --use-bitmap-index ignores pathspec silently?
Quoted 28 lines
Documentation/git-rev-list.txt | 1 + builtin/rev-list.c | 1 + 2 files changed, 2 insertions(+)Documentation/git-rev-list.txt +1
-0@@ -56,6 +56,7 @@ SYNOPSIS [ --reverse ] [ --walk-reflogs ] [ --no-walk ] [ --do-walk ] + [ --count ] [ --use-bitmap-index ] <commit>... [ \-- <paths>... ]builtin/rev-list.c +1
-0@@ -42,6 +42,7 @@ static const char rev_list_usage[] =" --abbrev=<n> | --no-abbrev\n" " --abbrev-commit\n" " --left-right\n" +" --count\n" " special purpose:\n" " --bisect\n" " --bisect-vars\n"
PATCH 1/1 rev-list: disable --use-bitmap-index when pruning commits
Quoted 3 lines · Junio C Hamano
Sounds good. While at it, perhaps add a mention (perhaps by creating a BUGS section at the end of the file) that --count with --use-bitmap-index ignores pathspec silently?
I think we can just fix it rather than documenting the problem. :)
-- >8 --
Subject: rev-list: disable --use-bitmap-index when pruning commits
The reachability bitmaps do not have enough information to tell us which commits might have changed path "foo", so the current code produces wrong answers for:
git rev-list --use-bitmap-index --count HEAD -- foo
(it silently ignores the "foo" limiter). Instead, we should fall back to doing a normal traversal (it is OK to fall back rather than complain, because --use-bitmap-index is a pure optimization, and might not kick in for other reasons, such as there being no bitmaps in the repository).
--- builtin/rev-list.c | 2 +- t/t5310-pack-bitmaps.sh | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-)
builtin/rev-list.c +1 -1
@@ -355,7 +355,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)if (bisect_list) revs.limited =1 ; -if (use_bitmap_index) { +if (use_bitmap_index && !revs.prune) {if (revs.count && !revs.left_right && !revs.cherry_mark) {uint32_t commit_count;if (!prepare_bitmap_walk (&revs)) {
t/t5310-pack-bitmaps.sh +6 -0
@@ -53,6 +53,12 @@ rev_list_tests() { test_cmp expect actual ' + test_expect_success "counting commits with limiting ($state)" ' + git rev-list --count HEAD -- 1.t >expect && + git rev-list --use-bitmap-index --count HEAD -- 1.t >actual && + test_cmp expect actual + ' + test_expect_success "enumerate --objects ($state)" ' git rev-list --objects --use-bitmap-index HEAD >tmp && cut -d" " -f1 <tmp >tmp2 &&
Signature · 1 line
2.5.0.rc0.336.g8460790
Re: [PATCH] rev-list: disable --use-bitmap-index when pruning commits
Quoted 7 lines · Jeff King
Quoted 3 lines · Junio C Hamano
Sounds good. While at it, perhaps add a mention (perhaps by creating a BUGS section at the end of the file) that --count with --use-bitmap-index ignores pathspec silently?
I think we can just fix it rather than documenting the problem. :)
;-) Good.
Will queue; thanks.
Quoted 52 lines
-- >8 --
Subject: rev-list: disable --use-bitmap-index when pruning commitsThe reachability bitmaps do not have enough information to tell us which commits might have changed path "foo", so the current code produces wrong answers for:
git rev-list --use-bitmap-index --count HEAD -- foo(it silently ignores the "foo" limiter). Instead, we should fall back to doing a normal traversal (it is OK to fall back rather than complain, because --use-bitmap-index is a pure optimization, and might not kick in for other reasons, such as there being no bitmaps in the repository).
Signed-off-by Jeff King <[email protected]>--- builtin/rev-list.c | 2 +- t/t5310-pack-bitmaps.sh | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-)builtin/rev-list.c +1
-1@@ -355,7 +355,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)if (bisect_list) revs.limited =1 ; -if (use_bitmap_index) { +if (use_bitmap_index && !revs.prune) {if (revs.count && !revs.left_right && !revs.cherry_mark) {uint32_t commit_count;if (!prepare_bitmap_walk (&revs)) {t/t5310-pack-bitmaps.sh +6
-0@@ -53,6 +53,12 @@ rev_list_tests() { test_cmp expect actual ' + test_expect_success "counting commits with limiting ($state)" ' + git rev-list --count HEAD -- 1.t >expect && + git rev-list --use-bitmap-index --count HEAD -- 1.t >actual && + test_cmp expect actual + ' + test_expect_success "enumerate --objects ($state)" ' git rev-list --objects --use-bitmap-index HEAD >tmp && cut -d" " -f1 <tmp >tmp2 &&