5

As a complete beginner to Go I'm not sure where to init Git.

The docs here https://golang.org/doc/code.html appear to suggest outside the hello directory early on and then later tell me to run git init inside the hello directory.

Any advice on this would be useful.

tommyd456
  • 10,443
  • 26
  • 89
  • 163

2 Answers2

6

The example is clear:

$ cd $GOPATH/src/github.com/user/hello
$ git init

You do initialize the repo within your project 'hello'.
That way:

  • you can push it to your GitHub repo (that you need to create first on GitHub, empty):

    git remote add origin https://<user>@github.com/<user>/hello
    git push -u origin master
    
  • your go project is "go gettable"

    go get github.com/<user>/hello
    # that would clone and compile the project in `$GOPATH/src/github.com/<user>/hello`.
    

The .git you see outside hello (on the same page) is for another project:

src/
    github.com/golang/example/
        .git/                      # Git repository metadata
    hello/
        hello.go               # command source

Here, the project is 'example' and include several packages, including the hello one.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Why is there a `.git/` directory above the hello directory in the directory structure? – tommyd456 Apr 15 '15 at 20:45
  • @tommyd456 I was editing my answer to address precisely that. – VonC Apr 15 '15 at 20:45
  • oh right - that's the bit that confused me and why I didn't find it clear. Thanks for that. – tommyd456 Apr 15 '15 at 20:47
  • What is the recommendation to not have random versions all jumbled together? If I compile my code at a particular commit, then it should have references to the other modules at the commits that they were compiled at. – Rob Apr 15 '15 at 20:50
  • @Rob There is a big debate about that: https://groups.google.com/forum/m/#!topic/golang-dev/nMWoEAG55v8. Vendoring seems to be the main solution. – VonC Apr 15 '15 at 20:51
  • Note that this problem is bigger than golang as well. If you have a large project split into hundreds of git repos (we do), then you ultimately need to be able to wrap git to checkout/branch/rebase-with-conflicts/merge/push groups of repos in a pseudo-transactional way. Having a way to handle references to large binaries is part of the the solution, but you need to be able to checkout the code that corresponds to exactly what created a historical build. – Rob Apr 15 '15 at 20:56
  • @Rob for git repos in general, that would be using submodules (http://stackoverflow.com/a/1979194/6309) – VonC Apr 15 '15 at 21:00
  • In some cases, yes. But it's not quite that simple. Git submodules handles source repo to source repo dependencies. When you have hundreds of repos that would take days to compile from source (we do), you generally have source to *build* dependencies (where builds reference a repo commit, or an immutable artifact like a jar file). – Rob Apr 15 '15 at 22:26
  • ie: a product CD was built from 200 git repos, some are conflicting versions of same repo even. you want to check out 4 or 5 of them to edit and make a product CD to test it. it's a dependency graph where commits reference built versions of other repo's commits. the builds are named after the commits they were built from so you can view and edit the source that created them. – Rob Apr 15 '15 at 22:32
  • submodules are also orthogonal to uniformly creating/rebasing/switching/pushing a bug branch as one item... as if they are just conceptually part of a multi-gigabyte git repo. – Rob Apr 15 '15 at 22:36
0

You'd want to initialize it at the same level as it would have been if you'd run go get github.com/user/hello - i.e. in the hello directory.

Basically, if you initialize git, push your repo up an go get again, nothing should change.

Sudhir Jonathan
  • 16,998
  • 13
  • 66
  • 90
  • I see - and typically that `hello.go` file would be `main.go` right when moving into "real" projects? – tommyd456 Apr 15 '15 at 20:51
  • If hello it a library, it would probably stay as `hello.go`. If your project is meant to be an executable, `main.go` is going to be necessary. But either way the package name is more important. – Sudhir Jonathan Apr 15 '15 at 20:52