Re: [PATCH v3] fetch: optionally allow disabling FETCH_HEAD update
From: Junio C Hamano <hidden>
Date: 2020-08-14 01:32:50
Derrick Stolee [off-list ref] writes:
quoted
* So, it becomes much smaller by punting the whole configuration thing, as we do not need the extra code for config parsing and there is no need for code to override the user configuration when driving "git fetch" from "git pull".Sounds good. I'll incorporate this patch into my next version, except it seems you dropped this test:
Yup. As we are not touching "pull" at all, the test I removed would make as much sense as a hypothetical one where its "git pull" is replaced with "git cat-file" or any other unrelated subcommand, and that is why I removed it. But I am OK if you resurrect it---everybody thinks "fetch" and "pull" are closely related after all. Thanks.
quoted hunk
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh index 159afa7ac8..db1a381cd9 100755 --- a/t/t5521-pull-options.sh +++ b/t/t5521-pull-options.sh@@ -85,6 +85,13 @@ test_expect_success 'git pull --cleanup errors early on invalid argument' ' test -s err) ' +test_expect_success 'git pull --no-write-fetch-head fails' ' + mkdir clonedwfh && + (cd clonedwfh && git init && + test_expect_code 129 git pull --no-write-fetch-head "../parent" >out 2>err && + test_must_be_empty out && + test_i18ngrep "no-write-fetch-head" err) +' test_expect_success 'git pull --force' ' mkdir clonedoldstyle &&which I changed "test_must_fail" to "test_expect_code 129" to demonstrate that this is a usage error, not just any error. Thanks, -Stolee