| # Frequently Asked Questions (F.A.Q.) | 
 |  | 
 | ## Q: Why does Glide have the concept of sub-packages when Go doesn't? | 
 |  | 
 | In Go every directory is a package. This works well when you have one repo containing all of your packages. When you have different packages in different VCS locations things become a bit more complicated. A project containing a collection of packages should be handled with the same information including the version. By grouping packages this way we are able to manage the related information. | 
 |  | 
 | ## Q: bzr (or hg) is not working the way I expected. Why? | 
 |  | 
 | These are works in progress, and may need some additional tuning. Please take a look at the [vcs package](https://github.com/masterminds/vcs). If you see a better way to handle it please let us know. | 
 |  | 
 | ## Q: Should I check `vendor/` into version control? | 
 |  | 
 | That's up to you. It's a personal or organizational decision. Glide will help you install the outside dependencies on demand or help you manage the dependencies as they are checked into your version control system. | 
 |  | 
 | By default, commands such as `glide update` and `glide install` install on-demand. To manage a vendor folder that's checked into version control use the flags: | 
 |  | 
 | * `--update-vendored` (aliased to `-u`) to update the vendored dependencies. | 
 | * `--strip-vcs` (aliased to `-s`) to strip VCS metadata (e.g., `.git` directories) from the `vendor` folder. | 
 | * `--strip-vendor` (aliased to `-v`) to strip nested `vendor/` directories. | 
 |  | 
 | ## Q: How do I import settings from GPM, Godep, Gom, or GB? | 
 |  | 
 | There are two parts to importing. | 
 |  | 
 | 1. If a package you import has configuration for GPM, Godep, Gom, or GB Glide will recursively install the dependencies automatically. | 
 | 2. If you would like to import configuration from GPM, Godep, Gom, or GB to Glide see the `glide import` command. For example, you can run `glide import godep` for Glide to detect the projects Godep configuration and generate a `glide.yaml` file for you. | 
 |  | 
 | Each of these will merge your existing `glide.yaml` file with the | 
 | dependencies it finds for those managers, and then emit the file as | 
 | output. **It will not overwrite your glide.yaml file.** | 
 |  | 
 | You can write it to file like this: | 
 |  | 
 |     $ glide import godep -f glide.yaml | 
 |  | 
 |  | 
 | ## Q: Can Glide fetch a package based on OS or Arch? | 
 |  | 
 | Yes. Using the `os` and `arch` fields on a `package`, you can specify | 
 | which OSes and architectures the package should be fetched for. For | 
 | example, the following package will only be fetched for 64-bit | 
 | Darwin/OSX systems: | 
 |  | 
 |     - package: some/package | 
 |       os: | 
 |         - darwin | 
 |       arch: | 
 |         - amd64 | 
 |  | 
 | The package will not be fetched for other architectures or OSes. | 
 |  | 
 | ## Q: How did Glide get its name? | 
 |  | 
 | Aside from being catchy, "glide" is a contraction of "Go Elide". The | 
 | idea is to compress the tasks that normally take us lots of time into a | 
 | just a few seconds. |