git/t/t5574-fetch-output.sh

305 lines
9.1 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='git fetch output format'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
test_expect_success 'fetch with invalid output format configuration' '
test_when_finished "rm -rf clone" &&
git clone . clone &&
test_must_fail git -C clone -c fetch.output fetch origin 2>actual.err &&
cat >expect <<-EOF &&
error: missing value for ${SQ}fetch.output${SQ}
fatal: unable to parse ${SQ}fetch.output${SQ} from command-line config
EOF
test_cmp expect actual.err &&
test_must_fail git -C clone -c fetch.output= fetch origin 2>actual.err &&
cat >expect <<-EOF &&
fatal: invalid value for ${SQ}fetch.output${SQ}: ${SQ}${SQ}
EOF
test_cmp expect actual.err &&
test_must_fail git -C clone -c fetch.output=garbage fetch origin 2>actual.err &&
cat >expect <<-EOF &&
fatal: invalid value for ${SQ}fetch.output${SQ}: ${SQ}garbage${SQ}
EOF
test_cmp expect actual.err
'
test_expect_success 'fetch aligned output' '
git clone . full-output &&
test_commit looooooooooooong-tag &&
(
cd full-output &&
git -c fetch.output=full fetch origin >actual 2>&1 &&
grep -e "->" actual | cut -c 22- >../actual
) &&
cat >expect <<-\EOF &&
main -> origin/main
looooooooooooong-tag -> looooooooooooong-tag
EOF
test_cmp expect actual
'
test_expect_success 'fetch compact output' '
git clone . compact &&
test_commit extraaa &&
(
cd compact &&
git -c fetch.output=compact fetch origin >actual 2>&1 &&
grep -e "->" actual | cut -c 22- >../actual
) &&
cat >expect <<-\EOF &&
main -> origin/*
extraaa -> *
EOF
test_cmp expect actual
'
test_expect_success 'setup for fetch porcelain output' '
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
# Set up a bunch of references that we can use to demonstrate different
# kinds of flag symbols in the output format.
test_commit commit-for-porcelain-output &&
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
MAIN_OLD=$(git rev-parse HEAD) &&
git branch "fast-forward" &&
git branch "deleted-branch" &&
git checkout -b force-updated &&
test_commit --no-tag force-update-old &&
FORCE_UPDATED_OLD=$(git rev-parse HEAD) &&
git checkout main &&
# Backup to preseed.git
git clone --mirror . preseed.git &&
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
# Continue changing our local references.
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
git branch new-branch &&
git branch -d deleted-branch &&
git checkout fast-forward &&
test_commit --no-tag fast-forward-new &&
FAST_FORWARD_NEW=$(git rev-parse HEAD) &&
git checkout force-updated &&
git reset --hard HEAD~ &&
test_commit --no-tag force-update-new &&
FORCE_UPDATED_NEW=$(git rev-parse HEAD)
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
'
for opt in "" "--atomic"
do
test_expect_success "fetch porcelain output ${opt:+(atomic)}" '
test_when_finished "rm -rf porcelain" &&
# Clone and pre-seed the repositories. We fetch references into two
# namespaces so that we can test that rejected and force-updated
# references are reported properly.
refspecs="refs/heads/*:refs/unforced/* +refs/heads/*:refs/forced/*" &&
git clone preseed.git porcelain &&
git -C porcelain fetch origin $opt $refspecs &&
cat >expect <<-EOF &&
- $MAIN_OLD $ZERO_OID refs/forced/deleted-branch
- $MAIN_OLD $ZERO_OID refs/unforced/deleted-branch
$MAIN_OLD $FAST_FORWARD_NEW refs/unforced/fast-forward
! $FORCE_UPDATED_OLD $FORCE_UPDATED_NEW refs/unforced/force-updated
* $ZERO_OID $MAIN_OLD refs/unforced/new-branch
$MAIN_OLD $FAST_FORWARD_NEW refs/forced/fast-forward
+ $FORCE_UPDATED_OLD $FORCE_UPDATED_NEW refs/forced/force-updated
* $ZERO_OID $MAIN_OLD refs/forced/new-branch
$MAIN_OLD $FAST_FORWARD_NEW refs/remotes/origin/fast-forward
+ $FORCE_UPDATED_OLD $FORCE_UPDATED_NEW refs/remotes/origin/force-updated
* $ZERO_OID $MAIN_OLD refs/remotes/origin/new-branch
EOF
# Change the URL of the repository to fetch different references.
git -C porcelain remote set-url origin .. &&
# Execute a dry-run fetch first. We do this to assert that the dry-run
# and non-dry-run fetches produces the same output. Execution of the
# fetch is expected to fail as we have a rejected reference update.
test_must_fail git -C porcelain fetch $opt \
--porcelain --dry-run --prune origin $refspecs >actual &&
test_cmp expect actual &&
# And now we perform a non-dry-run fetch.
test_must_fail git -C porcelain fetch $opt \
--porcelain --prune origin $refspecs >actual 2>stderr &&
test_cmp expect actual &&
test_must_be_empty stderr
'
done
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
test_expect_success 'fetch porcelain with multiple remotes' '
test_when_finished "rm -rf porcelain" &&
git switch --create multiple-remotes &&
git clone . porcelain &&
git -C porcelain remote add second-remote "$PWD" &&
git -C porcelain fetch second-remote &&
test_commit --no-tag multi-commit &&
old_commit=$(git rev-parse HEAD~) &&
new_commit=$(git rev-parse HEAD) &&
cat >expect <<-EOF &&
$old_commit $new_commit refs/remotes/origin/multiple-remotes
$old_commit $new_commit refs/remotes/second-remote/multiple-remotes
EOF
git -C porcelain fetch --porcelain --all >actual 2>stderr &&
test_cmp expect actual &&
test_must_be_empty stderr
'
test_expect_success 'fetch porcelain refuses to work with submodules' '
test_when_finished "rm -rf porcelain" &&
cat >expect <<-EOF &&
fatal: options ${SQ}--porcelain${SQ} and ${SQ}--recurse-submodules${SQ} cannot be used together
EOF
git init porcelain &&
test_must_fail git -C porcelain fetch --porcelain --recurse-submodules=yes 2>stderr &&
test_cmp expect stderr &&
test_must_fail git -C porcelain fetch --porcelain --recurse-submodules=on-demand 2>stderr &&
test_cmp expect stderr
'
test_expect_success 'fetch porcelain overrides fetch.output config' '
test_when_finished "rm -rf porcelain" &&
git switch --create config-override &&
git clone . porcelain &&
test_commit new-commit &&
old_commit=$(git rev-parse HEAD~) &&
new_commit=$(git rev-parse HEAD) &&
cat >expect <<-EOF &&
$old_commit $new_commit refs/remotes/origin/config-override
* $ZERO_OID $new_commit refs/tags/new-commit
EOF
git -C porcelain -c fetch.output=compact fetch --porcelain >stdout 2>stderr &&
test_must_be_empty stderr &&
test_cmp expect stdout
'
test_expect_success 'fetch --no-porcelain overrides previous --porcelain' '
test_when_finished "rm -rf no-porcelain" &&
git switch --create no-porcelain &&
git clone . no-porcelain &&
test_commit --no-tag no-porcelain &&
old_commit=$(git rev-parse --short HEAD~) &&
new_commit=$(git rev-parse --short HEAD) &&
cat >expect <<-EOF &&
From $(test-tool path-utils real_path .)/.
$old_commit..$new_commit no-porcelain -> origin/no-porcelain
EOF
git -C no-porcelain fetch --porcelain --no-porcelain >stdout 2>stderr &&
test_cmp expect stderr &&
test_must_be_empty stdout
'
fetch: print left-hand side when fetching HEAD:foo `store_updated_refs()` parses the remote reference for two purposes: - It gets used as a note when writing FETCH_HEAD. - It is passed through to `display_ref_update()` to display updated references in the following format: ``` * branch master -> master ``` In most cases, the parsed remote reference is the prettified reference name and can thus be used for both cases. But if the remote reference is HEAD, the parsed remote reference becomes empty. This is intended when we write the FETCH_HEAD, where we skip writing the note in that case. But when displaying the updated references this leads to inconsistent output where the left-hand side of reference updates is missing in some cases: ``` $ git fetch origin HEAD HEAD:explicit-head :implicit-head main From https://github.com/git/git * branch HEAD -> FETCH_HEAD * [new ref] -> explicit-head * [new ref] -> implicit-head * branch main -> FETCH_HEAD ``` This behaviour has existed ever since the table-based output has been introduced for git-fetch(1) via 165f390250 (git-fetch: more terse fetch output, 2007-11-03) and was never explicitly documented either in the commit message or in any of our tests. So while it may not be a bug per se, it feels like a weird inconsistency and not like it was a concious design decision. The logic of how we compute the remote reference name that we ultimately pass to `display_ref_update()` is not easy to follow. There are three different cases here: - When the remote reference name is "HEAD" we set the remote reference name to the empty string. This is the case that causes the left-hand side to go missing, where we would indeed want to print "HEAD" instead of the empty string. This is what `prettify_refname()` would return. - When the remote reference name has a well-known prefix then we strip this prefix. This matches what `prettify_refname()` does. - Otherwise, we keep the fully qualified reference name. This also matches what `prettify_refname()` does. As the return value of `prettify_refname()` would do the correct thing for us in all three cases, we can thus fix the inconsistency by passing through the full remote reference name to `display_ref_update()`, which learns to call `prettify_refname()`. At the same time, this also simplifies the code a bit. Note that this patch also changes formatting of the block that computes the "kind" (which is the category like "branch" or "tag") and "what" (which is the prettified reference name like "master" or "v1.0") variables. This is done on purpose so that it is part of the diff, hopefully making the change easier to comprehend. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:15 +00:00
test_expect_success 'fetch output with HEAD' '
test_when_finished "rm -rf head" &&
git clone . head &&
git -C head fetch --dry-run origin HEAD >actual.out 2>actual.err &&
cat >expect <<-EOF &&
From $(test-tool path-utils real_path .)/.
* branch HEAD -> FETCH_HEAD
EOF
test_must_be_empty actual.out &&
test_cmp expect actual.err &&
git -C head fetch origin HEAD >actual.out 2>actual.err &&
test_must_be_empty actual.out &&
test_cmp expect actual.err &&
git -C head fetch --dry-run origin HEAD:foo >actual.out 2>actual.err &&
cat >expect <<-EOF &&
From $(test-tool path-utils real_path .)/.
* [new ref] HEAD -> foo
EOF
test_must_be_empty actual.out &&
test_cmp expect actual.err &&
git -C head fetch origin HEAD:foo >actual.out 2>actual.err &&
test_must_be_empty actual.out &&
test_cmp expect actual.err
'
fetch: introduce machine-parseable "porcelain" output format The output of git-fetch(1) is obviously designed for consumption by users, only: we neatly columnize data, we abbreviate reference names, we print neat arrows and we don't provide information about actual object IDs that have changed. This makes the output format basically unusable in the context of scripted invocations of git-fetch(1) that want to learn about the exact changes that the command performs. Introduce a new machine-parseable "porcelain" output format that is supposed to fix this shortcoming. This output format is intended to provide information about every reference that is about to be updated, the old object ID that the reference has been pointing to and the new object ID it will be updated to. Furthermore, the output format provides the same flags as the human-readable format to indicate basic conditions for each reference update like whether it was a fast-forward update, a branch deletion, a rejected update or others. The output format is quite simple: ``` <flag> <old-object-id> <new-object-id> <local-reference>\n ``` We assume two conditions which are generally true: - The old and new object IDs have fixed known widths and cannot contain spaces. - References cannot contain newlines. With these assumptions, the output format becomes unambiguously parseable. Furthermore, given that this output is designed to be consumed by scripts, the machine-readable data is printed to stdout instead of stderr like the human-readable output is. This is mostly done so that other data printed to stderr, like error messages or progress meters, don't interfere with the parseable data. A notable ommission here is that the output format does not include the remote from which a reference was fetched, which might be important information especially in the context of multi-remote fetches. But as such a format would require us to print the remote for every single reference update due to parallelizable fetches it feels wasteful for the most likely usecase, which is when fetching from a single remote. In a similar spirit, a second restriction is that this cannot be used with `--recurse-submodules`. This is because any reference updates would be ambiguous without also printing the repository in which the update happens. Considering that both multi-remote and submodule fetches are user-facing features, using them in conjunction with `--porcelain` that is intended for scripting purposes is likely not going to be useful in the majority of cases. With that in mind these restrictions feel acceptable. If usecases for either of these come up in the future though it is easy enough to add a new "porcelain-v2" format that adds this information. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:36 +00:00
test_expect_success 'fetch porcelain output with HEAD' '
test_when_finished "rm -rf head" &&
git clone . head &&
COMMIT_ID=$(git rev-parse HEAD) &&
git -C head fetch --porcelain --dry-run origin HEAD >actual &&
cat >expect <<-EOF &&
* $ZERO_OID $COMMIT_ID FETCH_HEAD
EOF
test_cmp expect actual &&
git -C head fetch --porcelain origin HEAD >actual &&
test_cmp expect actual &&
git -C head fetch --porcelain --dry-run origin HEAD:foo >actual &&
cat >expect <<-EOF &&
* $ZERO_OID $COMMIT_ID refs/heads/foo
EOF
test_cmp expect actual &&
git -C head fetch --porcelain origin HEAD:foo >actual &&
test_cmp expect actual
'
fetch: print left-hand side when fetching HEAD:foo `store_updated_refs()` parses the remote reference for two purposes: - It gets used as a note when writing FETCH_HEAD. - It is passed through to `display_ref_update()` to display updated references in the following format: ``` * branch master -> master ``` In most cases, the parsed remote reference is the prettified reference name and can thus be used for both cases. But if the remote reference is HEAD, the parsed remote reference becomes empty. This is intended when we write the FETCH_HEAD, where we skip writing the note in that case. But when displaying the updated references this leads to inconsistent output where the left-hand side of reference updates is missing in some cases: ``` $ git fetch origin HEAD HEAD:explicit-head :implicit-head main From https://github.com/git/git * branch HEAD -> FETCH_HEAD * [new ref] -> explicit-head * [new ref] -> implicit-head * branch main -> FETCH_HEAD ``` This behaviour has existed ever since the table-based output has been introduced for git-fetch(1) via 165f390250 (git-fetch: more terse fetch output, 2007-11-03) and was never explicitly documented either in the commit message or in any of our tests. So while it may not be a bug per se, it feels like a weird inconsistency and not like it was a concious design decision. The logic of how we compute the remote reference name that we ultimately pass to `display_ref_update()` is not easy to follow. There are three different cases here: - When the remote reference name is "HEAD" we set the remote reference name to the empty string. This is the case that causes the left-hand side to go missing, where we would indeed want to print "HEAD" instead of the empty string. This is what `prettify_refname()` would return. - When the remote reference name has a well-known prefix then we strip this prefix. This matches what `prettify_refname()` does. - Otherwise, we keep the fully qualified reference name. This also matches what `prettify_refname()` does. As the return value of `prettify_refname()` would do the correct thing for us in all three cases, we can thus fix the inconsistency by passing through the full remote reference name to `display_ref_update()`, which learns to call `prettify_refname()`. At the same time, this also simplifies the code a bit. Note that this patch also changes formatting of the block that computes the "kind" (which is the category like "branch" or "tag") and "what" (which is the prettified reference name like "master" or "v1.0") variables. This is done on purpose so that it is part of the diff, hopefully making the change easier to comprehend. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-10 12:34:15 +00:00
test_expect_success 'fetch output with object ID' '
test_when_finished "rm -rf object-id" &&
git clone . object-id &&
commit=$(git rev-parse HEAD) &&
git -C object-id fetch --dry-run origin $commit:object-id >actual.out 2>actual.err &&
cat >expect <<-EOF &&
From $(test-tool path-utils real_path .)/.
* [new ref] $commit -> object-id
EOF
test_must_be_empty actual.out &&
test_cmp expect actual.err &&
git -C object-id fetch origin $commit:object-id >actual.out 2>actual.err &&
test_must_be_empty actual.out &&
test_cmp expect actual.err
'
test_expect_success '--no-show-forced-updates' '
mkdir forced-updates &&
(
cd forced-updates &&
git init &&
test_commit 1 &&
test_commit 2
) &&
git clone forced-updates forced-update-clone &&
git clone forced-updates no-forced-update-clone &&
git -C forced-updates reset --hard HEAD~1 &&
(
cd forced-update-clone &&
git fetch --show-forced-updates origin 2>output &&
test_grep "(forced update)" output
) &&
(
cd no-forced-update-clone &&
git fetch --no-show-forced-updates origin 2>output &&
test_grep ! "(forced update)" output
)
'
test_done