Hi Christopher! Thanks for the report. Cc-ing Git mailing list; do keep the mailing list in the loop in the future, it'll also let you get a response from someone other than Junio (who is probably busy with post 2.38 work) or me :) I have responded in-line, but otherwise the email I am responding to is intact. Christopher Layne <clayne@xxxxxxxxxxxx> writes: >> On Oct 12, 2022, at 1359 PT, Christopher Layne <clayne@xxxxxxxxxxxx> wrote: >> >> This change causes a regression in expected output for the single remote case: >> >> e.g.: >> >> gclayne@dorian:~/git/cmake (master =) $ git fetch --all >> From https://gitlab.kitware.com/cmake/cmake >> 0a45aa7525..f6af01b53d master -> origin/master >> >> vs: >> >> clayne@i860:~/git/cmake (master=) $ git fetch --all >> Fetching origin >> From https://gitlab.kitware.com/cmake/cmake >> 0a45aa7525..f6af01b53d master -> origin/master >> >> There may be any manner of output parsers involved in automation or other scripts looking >> for the remote to be emitted before the actual url portion and in fact it broke one of mine, >> hence how I even stumbled upon this. Since the remote name is no longer emitted in the >> single remote case it deviates from the expected output that's been present for years now >> and is likely to trip up all manner of people and automation which may depend on it. The commit in question (which you've identified correctly) is 0353c68818 (fetch: do not run a redundant fetch from submodule, 2022-05-16). "git describe" tells me that this has been with us since 2.36, so it is not a recent regression at least. This commit changes "git fetch --all" so that if a single remote would be fetched, we call fetch_one() (which does not print "Fetching remote....") instead of fetch_multiple() (which prints the message you expect). In [1], Junio spotted that we performed exactly this 'optimization' when a remote group expands to only one remote. So, in a sense, this commit makes "git fetch" more self consistent between "--all" and remote groups, but this more consistent behavior seems undesired by at least one bug reporter. [1] https://lore.kernel.org/git/xmqqwnel1eqb.fsf@gitster.g/ > > Note: it also implicitly makes the output "quiet" in the single remote case: > > Original approach: > > clayne@i860:/tmp/git-test/cmake (master<) $ git fetch --all > Fetching origin > > clayne@i860:/tmp/git-test/cmake (master<) $ git fetch --all --quiet > clayne@i860:/tmp/git-test/cmake (master<) $ > > New approach: > > clayne@dorian:~/git/cmake (master <) $ git fetch --all > clayne@dorian:~/git/cmake (master <) $ > > clayne@dorian:~/git/cmake (master <) $ git remote add origin2 -f https://gitlab.kitware.com/cmake/cmake.git > Updating origin2 > From https://gitlab.kitware.com/cmake/cmake > * [new branch] master -> origin2/master > * [new branch] release -> origin2/release > > clayne@dorian:~/git/cmake (master <) $ git fetch --all > Fetching origin > Fetching origin2 > clayne@dorian:~/git/cmake (master <) $ git fetch --all --quiet > clayne@dorian:~/git/cmake (master <) $ This is the same behavior reported above; the input isn't becoming quiet, only that "--quiet" suppresses that same message that is no longer being output. > The output is now inconsistent and unpredictable because it depends on the amount of remotes > present for a given repo. If there is a single remote, "Fetching %s" is absent. If there are > multiple remotes it behaves as normal. This breaks parsers and since there is no official > spec on the output, other than the man page, people have come to rely on parsing the output > as a means of determining progress/status for their own automation involving git. > multiple remotes it behaves as normal. This breaks parsers and since there is no official > spec on the output, other than the man page, people have come to rely on parsing the output I'm not sure whether to treat a change like this as a regression. I suspect that the lack of an official spec is by design, as it signals to end users that this is not behavior that has been promised and is prone to change. I personally don't think we should start promising that the "git fetch" output will be well-structured and will not change either, because the output is meant to be read by humans, who tend to be much more forgiving than scripts. All said, I do empathize with your use case. This isn't just "your change in the output format broke my script", but "information that used to be there isn't there any more, so I can't even update my script". A reasonable compromise might be to log "Fetching %s" when fetching a single remote in "git fetch --verbose", e.g. diff --git a/builtin/fetch.c b/builtin/fetch.c index a0fca93bb6..7f811e115c 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -2085,6 +2085,10 @@ static int fetch_one(struct remote *remote, int argc, const char **argv, if (server_options.nr) gtransport->server_options = &server_options; + + if (verbosity >= 1) + printf(_("Fetching %s\n"), remote->name); + sigchain_push_common(unlock_pack_on_signal); atexit(unlock_pack_atexit); sigchain_push(SIGPIPE, SIG_IGN); I could see this as a reasonable QoL improvement for some humans. This is _still_ only meant for humans, and doesn't change my opinion that this is unpromised behavior. If you are looking for promised, well-behaved output, you're welcome to propose something like "git status --porcelain" for "git fetch", where the output format is well-documented and stable. > > -cl
