[Go] Update ignore patterns. #2266
Merged
Conversation
|
/cc @shiftkey |
|
@AlekSi given the significant number of |
This comment has been minimized.
This comment has been minimized.
|
Hi there, I have a question. Why removing the vendor folder? Any reason behind that? |
This comment has been minimized.
This comment has been minimized.
|
See #2266 |
u9E9F
pushed a commit
to u9E9F/gitignore
that referenced
this pull request
Jul 8, 2017
[Go] Update ignore patterns.
Closed
Closed
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.
Remove old patterns for legacy Go versions (pre 1.0, when
Makefiles were used instead ofgocommand).It hurts me to see those remnants over and over again.
Remove
vendor/.To quote https://blog.gopheracademy.com/advent-2015/vendor-folder/:
Go doesn't have widely used
gemand rubygems.org equivalent yet. Instead, several third-party tools are used, which fetch dependencies from Github and other places, and lock versions to particular commit hashes.gotool is then used to build programs.gois aware ofvendor/directory, but knows nothing about lock files, commit hashes, etc. Ifvendor/is not included in the repository, thengo getwill download sources – but it will be the latest commit for each import path (more or less is equivalent of repository URL), not specified commits from lock file. In you are lucky, and all package authors do care about backward compatibility (but that's not true in general – many packages are broken regularly), it may work. If you are less lucky, you will get a broken build. In the worst case, your code will explode in runtime, not during compilation. Therefore, I'm strongly for inclusion ofvendor/. I think the majority of the community thinks the same way.Even people who disagree with this opinion would agree that omitting
vendor/should be opt-in, not opt-out.Related pull requests:
#2198 (closed as duplicate).
#2183 (closed due to conflicts).