2023-05-10 12:34:07 +00:00
|
|
|
#!/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
|
|
|
|
|
|
2023-05-10 12:34:11 +00:00
|
|
|
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
|
|
|
|
|
'
|
|
|
|
|
|
2023-05-10 12:34:07 +00:00
|
|
|
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
|
|
|
|
|
'
|
|
|
|
|
|
2023-12-17 14:11:33 +00:00
|
|
|
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.
|
2023-12-17 14:11:33 +00:00
|
|
|
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 &&
|
|
|
|
|
|
2023-12-17 14:11:33 +00:00
|
|
|
# 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
|
|
|
|
2023-12-17 14:11:33 +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 &&
|
2023-12-17 14:11:33 +00:00
|
|
|
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
|
|
|
'
|
|
|
|
|
|
2023-12-17 14:11:33 +00:00
|
|
|
for opt in "" "--atomic"
|
|
|
|
|
do
|
2023-12-17 14:11:34 +00:00
|
|
|
test_expect_success "fetch porcelain output ${opt:+(atomic)}" '
|
2023-12-17 14:11:33 +00:00
|
|
|
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
|
|
|
|
|
'
|
|
|
|
|
|
2023-05-10 12:34:07 +00:00
|
|
|
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 &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep "(forced update)" output
|
2023-05-10 12:34:07 +00:00
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd no-forced-update-clone &&
|
|
|
|
|
git fetch --no-show-forced-updates origin 2>output &&
|
2023-10-31 05:23:30 +00:00
|
|
|
test_grep ! "(forced update)" output
|
2023-05-10 12:34:07 +00:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_done
|