`glide update` or a install should do the job, yes. If that does not `mv vendor _vendor && glide install` to figure out if things works or are stinky.
Do you mean you re in situation where you have one to many repo to update by doing a fork / PR / merge to actually make a significant change into an entry point repo ? In another world i d suggest to checkout the forks then link them to your entry point, bypassing the manifest while your doing your changes. Once changes are ready, commit/push||bump the packages from the leafs to the root. unfortunately, afaik, package symlinking in go is not a suitable option, *so far*. I don t know what the package committee group has in mind on those use cases. It s actually not so different to mr campoy solution, except that one works on a global scope (GOPATH), and one works on a local scope (vendor/). > It feels weird to be masking the very repo I cloned to work in... Depends of the situation you are in. If you have read/write access to your repos (typically they re yours), solutionS above are way more effective. If you work on a repo in the wild which you are not able to merge in, masking is one way to go. > Can it work when the forked gh repo contains many packages that sometimes use each other? IRL, i did not face the case with glide, so far. IMVVHO, yes it should. There should be a way to give priority to the top level manifest to constraint the tree. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
