Just realized how easy to do vendoring with Go 1.5 for your organization

[Hǎiliàng]

No 3rd party tools are needed at all.

Say the repositories of your organization are under:
$GOPATH/src/your_org/

1. create a vendor repo in your organization:

$GOPATH/src/your_org/vendor

2. all vendor repos should be under the "your_org/vendor" repo as Git submodules nested under their directories:

$GOPATH/src/your_org/vendor/github.com/repo1
$GOPATH/src/your_org/vendor/github.com/repo2

3. Ta da!

Hǎiliàng

[Tim K]

My personal experience with git submodules in general has been terrible and I don't seem to be alone. Plus some may not use git to make use of submodules. I think go vendoring tools are valuable.

[Matt Harden]

Many people have difficulty with git submodules, but once it "clicked" for me, it made a whole lot of sense. Now I have no trouble at all with them.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Waller]

I have also bitten the bullet.

A lot of problems seem to have been solved in recent years with more recent versions of git.

Support can still be a bit flaky at times, I've especially encountered issues when moving submodules around within a repository. Git can find itself in a state where it immediately gives a fatal error for any command you run, so you have to be prepared to go and fix state manually in some circumstances.

These issues are things which should get fixed in git, I hope.

On balance it seems worth it.

[Hǎiliàng Wáng]

I do not have much experience in Git submodule, however, I would like
to remind that vendoring needs only a tiny subset of operations that
Git submodules can do:

1. add a specific tagged version of Git repo as a submodule
2. upgrade a submodule to a higher tag

The vendor submodule is just a read-only mirror which is modified less
frequently.

Figure out what these commands are and follow the steps, do some
experiments before the real work if you do not have enough confidence,
and there is no chance to get wrong.

Also, if you feel the need to modify a 3rd party repo, just fork it
and it becomes a repo managed by yourself. There is no need to vendor
your own package.
Hǎiliàng

> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/NbThPX_b680/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Manlio Perillo]

Il giorno giovedì 17 settembre 2015 10:30:30 UTC+2, Hǎiliàng ha scritto:

I do not have much experience in Git submodule, however, I would like
to remind that vendoring needs only a tiny subset of operations that
Git submodules can do:

1. add a specific tagged version of Git repo as a submodule
2. upgrade a submodule to a higher tag

> [...] 

Also, if you feel the need to modify a 3rd party repo, just fork it
and it becomes a repo managed by yourself. There is no need to vendor
your own package.

In this case an alternative to submodules it to use the git subtree merging support:

https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

but it has its own sets of problems.

> [...] 

Regards  Manlio

[Hǎiliàng Wáng]

Hǎiliàng

>> Also, if you feel the need to modify a 3rd party repo, just fork it
>> and it becomes a repo managed by yourself. There is no need to vendor
>> your own package.

Please let me clarify:
1. if you want to modify a 3rd party repo, DO NOT do vendoring! (NO
submodules at all)
2. fork it directly on Github (e.g.) and use the new forked import path.

Use submodule ONLY as a simple mirror.

Hǎiliàng

[Tim K]

The submodules approach may work when all the dependencies are in git which is probably the case 99% of the time. But what do you do when you hit the first dependency that is not in git? I haven't found one yet that is not on github so maybe it's a non-issue in practice.

The other problem could be automated nightly builds. What happens if the external git server is down or maybe unreachable because of a network problem? Or the build machine can't reach out to the Internet to pull things (which is a real world problem in big companies with overly restrictive firewalls). Builds fail for no good reason.

I'm not saying that git submodules doesn't work, I'm just thinking out loud what problems it may introduce. It may be a perfectly acceptable solution for many many projects.

[Hǎiliàng Wáng]

Good point.

If the repo is not stable or not from Git, there are still workarounds:

1. copy the source code and check it into the vendor repo directly.
2. mirror the source code to another Git repo and then go back to the
submodule way.

Hǎiliàng