Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch all tags if there is tag spec. #720

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

autozimu
Copy link

@autozimu autozimu commented Jan 6, 2018

Ref #719.

@autozimu
Copy link
Author

autozimu commented Jan 6, 2018

Need more time to look into the tests.

@blueyed
Copy link
Contributor

blueyed commented Jan 15, 2018

Test failures might be unrelated: #724.

But likely could use a test itself.

@janlazo
Copy link
Collaborator

janlazo commented Oct 30, 2019

Build failed in a rebased branch.
https://travis-ci.org/junegunn/vim-plug/builds/604736561

@matthewarmand
Copy link

I'll preface this by saying this is a bit of an odd case, and if vim-plug doesn't want to support this case, that's understandable to me (but it would be good to get a statement from maintainers one way or the other).

Black (a python code formatter) does a somewhat interesting thing with tags where, in addition to having version tags, there's a stable tag which gets moved around to whatever the latest release is. Their editor installation docs instruct to use this with vim-plug (yes, I know, they say branch and should probably say tag, but that's the second issue here). By default, git fetch --tags and git pull --tags won't clobber existing tags if they've changed, but in this case that's exactly what needs to happen. (Related upstream issue: psf/black#2503) This can be fixed by using the force flag. So, for example git fetch/pull -q --tags --force.

So, if when fetching the tags (like in this PR) --force was also used, it would satisfy projects which have a stable or latest tag that moves around with new releases. Then Black's docs could be changed to something like Plug 'psf/black, { 'tag': 'stable' } and vim-plug would work for getting the latest stable version of the plugin.

Is this something maintainers would be ok with? I mention here because tag-fetching seems mostly done already here (failing tests notwithstanding)

@junegunn
Copy link
Owner

@matthewarmand

there's a stable tag which gets moved around

That's a strange practice. Not sure if we should enforce --force for an exceptional case.

But since they also publish version tags, you can do something like this:

" *.* to match version numbers
Plug 'psf/black', { 'tag': '*.*' }
Updated. Elapsed time: 2.342714 sec.
[=]

- Finishing ... Done!
- Latest tag for *.* -> 22.3.0 (black)
- black: Resolving deltas: 100% (5459/5459), done.

@matthewarmand
Copy link

Thanks @junegunn, I agree that's a much better solution. I'll open a PR soon over there suggesting that change in their docs (I had another addition I wanted to make anyway).

matthewarmand added a commit to matthewarmand/black that referenced this pull request Dec 20, 2022
… tag is an antipattern that doesn't re-resolve with vim-plug, see this discussion for more detail (junegunn/vim-plug#720). Per vim-plug's maintainer's recommendation, use the 'tag' key instead with a shell wildcard. Wildcard should be '*.*.*' as that follows Black's versioning detailed here (https://black.readthedocs.io/en/latest/contributing/release_process.html\#cutting-a-release) and doesn't include current alpha releases.
JelleZijlstra pushed a commit to psf/black that referenced this pull request Dec 20, 2022
* Organize vim plugin section with headers to separate out Installation, Usage, and Troubleshooting for readability and easy linking

* Add missing plugin configuration options, with current defaults

* Add installation note for Arch Linux, now that the plugin is shipped with the python-black package (ref: https://bugs.archlinux.org/task/73024)

* Fix vim-plug specification to follow stable releases. Moving the same tag is an antipattern that doesn't re-resolve with vim-plug, see this discussion for more detail (junegunn/vim-plug#720). Per vim-plug's maintainer's recommendation, use the 'tag' key instead with a shell wildcard. Wildcard should be '*.*.*' as that follows Black's versioning detailed here (https://black.readthedocs.io/en/latest/contributing/release_process.html\#cutting-a-release) and doesn't include current alpha releases.
hugovk pushed a commit to hugovk/black that referenced this pull request Jan 16, 2023
* Organize vim plugin section with headers to separate out Installation, Usage, and Troubleshooting for readability and easy linking

* Add missing plugin configuration options, with current defaults

* Add installation note for Arch Linux, now that the plugin is shipped with the python-black package (ref: https://bugs.archlinux.org/task/73024)

* Fix vim-plug specification to follow stable releases. Moving the same tag is an antipattern that doesn't re-resolve with vim-plug, see this discussion for more detail (junegunn/vim-plug#720). Per vim-plug's maintainer's recommendation, use the 'tag' key instead with a shell wildcard. Wildcard should be '*.*.*' as that follows Black's versioning detailed here (https://black.readthedocs.io/en/latest/contributing/release_process.html\#cutting-a-release) and doesn't include current alpha releases.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants