@@ -30,8 +30,6 @@ int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
opt->long_name);
if (v && v < MINIMUM_ABBREV)
v = MINIMUM_ABBREV;
- else if (startup_info->have_repository && v > the_hash_algo->hexsz)
- v = the_hash_algo->hexsz;
}
*(int *)(opt->value) = v;
return 0;
@@ -1243,12 +1243,24 @@ test_expect_success '--abbrev-commit with core.abbrev=false' '
test_cmp expect actual
'
+test_expect_success '--abbrev-commit with --no-abbrev' '
+ git log --no-abbrev >expect &&
+ git log --abbrev-commit --no-abbrev >actual &&
+ test_cmp expect actual
+'
+
test_expect_success '--abbrev-commit with core.abbrev=9000' '
git log --no-abbrev >expect &&
git -c core.abbrev=9000 log --abbrev-commit >actual &&
test_cmp expect actual
'
+test_expect_success '--abbrev-commit with --abbrev=9000' '
+ git log --no-abbrev >expect &&
+ git log --abbrev-commit --abbrev=9000 >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'show added path under "--follow -M"' '
# This tests for a regression introduced in v1.7.2-rc0~103^2~2
test_create_repo regression &&
The `OPT__ABBREV()` option allows the user to specify the length that object hashes shall be abbreviated to. This length needs to be in the range of `(MIN_ABBREV, the_hash_algo->hexsz)`, which is why we clamp the value as required. While this makes sense in the case of `MIN_ABBREV`, it is unnecessary for the upper boundary as the value is eventually passed down to `repo_find_unnique_abbrev_r()`, which handles values larger than the current hash length just fine. In the preceding commit, we have changed parsing of the "core.abbrev" config to stop clamping to the upper boundary. Let's do the same here so that the code becomes simpler, we are consistent with how we treat the "core.abbrev" config and so that we stop depending on `the_repository`. Signed-off-by: Patrick Steinhardt <ps@pks.im> --- parse-options-cb.c | 2 -- t/t4202-log.sh | 12 ++++++++++++ 2 files changed, 12 insertions(+), 2 deletions(-)