Repository navigation
Feature request: explicit fetch-depth:0 to also fetch tags #204
Description
v2 is great! It's much faster and optimized for most "main" scenarios of running tests or builds on the latest commit.
However, on tag events, a very common workflow is to publish the tag as a release somewhere (homebrew, npm, github releases, etc). A major component of most release flows is generating release notes which requires knowledge of prior tags.
Using v2, I expected fetch-depth:0 to make this possible.
Problematic run: https://github.com/nodenv/nodenv/runs/549286319?check_suite_focus=true
Error:
Run script/release-notes | tee relnotes.txt
fatal: No tags can describe '443076f046e3db1820d725f6d82947c55dcbdc8f'.
Try --always, or create some tags.
workflow:
steps:
- uses: actions/checkout@v2
with: { fetch-depth: 0 }
- run: script/release-notes | tee relnotes.txtMy hope is that when fetch-depth:0 is supplied (which implies we want all history) that tags will be fetched as well. I believe this would keep the non-tag "main" scenario fast as desired; while also making the most common tagging scenario more intuitive.
related to #100
Activity
ericsciple commentedon Mar 31, 2020
Also related to #155 - would be good to +1 that PR to help prioritize
ericsciple commentedon Mar 31, 2020
note,
fetch-depth: 0is currently MAX history but still just for the one ref.gitfool commentedon Apr 2, 2020
Nice idea which would mirror GitLab
GIT_DEPTHbehavior:That said, #155 would be more flexible.
beatngu13 commentedon Apr 3, 2020
This would also be useful when static code analysis tools such as SonarCloud are being used, which often require history forgit blame(see Travis docs for comparison). With adepthparameter, one could avoid the extra step forgit fetch --prune --unshallow.Overlooked
fetch-depthwithfetch-refs…jasonkarns commentedon Apr 3, 2020
Agree. I'm waffling on whether this feature would still even make sense if #155 were implemented.
I kind of think it would still be worthwhile for scenarios where I user's don't actually need all branch and tag refs, but only those reachable from current ref.
However, I could also see it leading to user confusion. I'll close this for now unless the maintainers consider this separately valuable.
ejsmith commentedon Apr 30, 2020
Why close this?? There needs to be a simple built in way without having to run separate commands to get full history with tags. #217