Repository navigation
Conversation
Author
|
Before and After Logs: https://github.com/proxy/gist.github.com/mostafazh/7badb07f545eb6d1913c382962b346cc (48% less in Number of Lines) |
Adds a `quiet` input (default: false) that passes `--quiet` to the git commands that fetch and check out the repository: `fetch`, `checkout`, `checkout --detach`, and `submodule update`. With `fetch-depth: 0` the refspec covers every branch and tag, so git prints a `From <url>` line plus one `* [new branch]` / `* [new tag]` line per ref. On a ref-heavy repository that summary is the bulk of the checkout log, and `show-progress: false` does not remove it -- that input only ever controlled `--progress`. `--quiet` and `--progress` drive different output and compose rather than conflict: `--progress` forces the transfer/update meter, while `--quiet` drops the ref summary and other informational messages. `checkout` keeps its `--progress` when quiet, so a slow checkout still reports progress. `git lfs fetch` has no `--quiet` flag, so LFS output is unchanged. Fixes actions#2409
mostafazh
force-pushed
the
mostafazh/Fix-Issue-2409
branch
from
September 7, 2026 20:55
4dae3c9 to
81a936f
Compare
Author
1 similar comment
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a
quietinput (defaultfalse) that passes--quietto the git commands checkout runs:fetch,checkout,checkout --detach, andsubmodule update.Fixes #2409.
Why
show-progress: falseis not enough#1067 made
--progressconditional, which handles the progress sideband. The noise reported in #2409 is a different thing: the per-ref fetch summary. Atfetch-depth: 0the refspec is+refs/heads/*:refs/remotes/origin/*plus+refs/tags/*:refs/tags/*, so git prints aFrom <url>line and then one* [new branch]/* [new tag]line for every ref in the repository. That output is not progress, so no--progresstoggle removes it.--quietdoes.Evidence
Three jobs on the same runner, all fetching the same repository (
actions/checkout, 61 branches + 68 tags) atfetch-depth: 0. The middle arm is a control — this branch withquiet: false— to show the change is inert unless the input is set.Fetching the repositorygroup* [new ...]linesactions/checkout@v7quiet: falsequiet: trueThe control arm's fetch group is content-identical to the baseline (0 differing lines once timestamps are stripped), so
quietis the only variable.Baseline:
With
quiet: true:Full run: https://github.com/mostafazh/checkout/actions/runs/33961567354 — workflow: https://github.com/mostafazh/checkout/blob/quiet-ab-test/.github/workflows/quiet-ab-test.yml
--progressvs--quietThese two drive different output channels and compose rather than conflict, so this PR passes both where both apply:
--progress/--no-progresscontrols only the progress meter (Receiving objects,Updating files: N%).-q/--quietcontrols verbosity: theFrom <url>+* [new ...]ref summary forfetch,Switched to branch ...forcheckout. It also turns the meter off as a side effect.When both are given, the meter follows
--progress(git evaluates forced progress before verbosity, andgit-checkout(1)says--progressapplies "regardless of--quiet"), while everything else stays suppressed by--quiet. Measured on git 2.50.1 overfile://with stderr not a terminal:git fetchflags--progress--quiet--quiet --progress--progress --quietOrder is irrelevant; each flag acts on its own channel. So
checkoutkeeps its unconditional--progressand merely gains--quiet, which means a large checkout still reports progress while the chatter goes away.Separate observation, not fixed here
While tracing this I noticed
show-progresscurrently has no effect.getSourcedeclaresshowProgress?: booleanon thefetchOptionsobject insrc/git-source-provider.tsbut never assignssettings.showProgressto it, sooptions.showProgressis alwaysundefinedand--progressis never passed tofetch. This is visible in the baseline log above: the step's resolved inputs reportshow-progress: true, yet the fetch command carries no--progress. It appears to date back to #1067, which added the field to the type but not the assignment.I have deliberately left it alone to keep this PR focused, and because wiring it up would make the default output noisier for everyone. Happy to open a separate issue or PR if you would like it addressed.
Notes
git lfs fetchhas no--quietflag, so LFS output is unchanged.false, so existing workflows are unaffected.Per CONTRIBUTING
__test__/git-command-manager.test.tsgains aTest quiet optionblock (11 cases) asserting the exact argv forfetch,checkoutwith and without a start point,checkoutDetachandsubmoduleUpdatein both the quiet and non-quiet states, plus--quiettaking precedence over--progressand the omitted-argument default staying non-quiet.__test__/input-helper.test.tscovers the input default and parsing.npm run test— 140 passingnpm run format— cleannpm run build—dist/index.jsrebuilt and committed