LGTM /cc @vieux

oooo. this might be useful in one project I work on - needs documentation though :)

on second thoughts, it might need to be made optional. iirc, there are hundreds of submodules, and some are pretty massive

Hmm.. A flag for build command?

@songgao I would suspect so, though I'm not thrilled about it (something long like --clone-git-recursive :/ )

Are there use cases where this wouldn't be the expected behavior with regards to git sub-modules?

@tianon i suspect so - in one submodule project I worked with, there was a core repo, with hundreds of submodules, resulting in several GB worth of data. If I were to dockerise that project, the submodules would all go into separate volume containers (as most of them were data).

Mind you, I can't recal if more than the core module would be needed to bootstrap the app-server container.

I'm trying to avoid judging the goodness of such an approach, but cloning, and then uploading several GB's to only use the core module would probably annoy the heck out of the docker user.

In that case though, are you going to be just passing Docker the GitHub URL and hoping for the best? Or are you going to clone locally and do the docker build against your local context?

Hmm.. that's a good point. So docker should provide a default behavior and if the user want it to behave otherwise, manually cloning will work. The "default behavior" would be the most common case

or the safest case? (I don't know enough git usage, so I can't say which way is best). My reading has only seen the (loudly) talked about cases where submodules are used because there's way too much stuff to have in one repo - which is what makes me wary of defaulting to --recursive.

I seriously don't have the massive scale git experience to know tho.

I honestly see docker build GIT_URL as more of a toy, but useful when you want to just build someone else's Dockerfile from GitHub but don't care to keep the source around (because you're already browsing it online or something). So in that context, I think --recursive is what people would expect, since it's the most likely to do what the Dockerfile author meant.

fair cop guv :)

ping @shykes - what're your thoughts on this?

As a packages, service or extensions provider / software vendor , docker build GIT_URL is a nice and convenience way to distribute apps.

As a developer for a company-wide software solution, I need to control carefully the project's building. The GIT_URL thing is not that useful (my ecosystem will be more complex for sure).

The --recursive flag is a nice default. Indeed adding other syntax parsing from the url and passing the info to the build process could be nice, for example:

• git build github.com/GermanDZ/dockers-repo/only-this could be indicate clone this repo, but use only-this as context
• git build github.com/GermanDZ/my-app#v0.7.8 could be indicate clone this repo, but use the tag 0.7.8
• git build github.com/GermanDZ/my-app#stable could be indicate clone this repo, but use the branch stable

@songgao are you interested in getting this merged? I needs the new DCO - https://github.com/dotcloud/docker/blob/master/CONTRIBUTING.md#sign-your-work

Each commit in your PR must be signed in the following format:
Docker-DCO-1.0-Signed-off-by: Joe Smith [email protected] (github: github_handle)

also, can you add a little documentation to the cli.rst please?

@GermanDZ that's also a good point - Might be good to create a new issue for it though - or even better mention it in the docker-dev list - there might be some discussion wrt syntax :)

@SvenDowideit Thanks for the link! I've added sign-off (and also a GPG signature) and some documentation about recursively cloning in cli.rst.

git push -fed so it would result in a cleaner git tree.

@songgao Can you rebase this on master, please?

It seems git clone was moved from api/api.go to server.go. Could either of you guys check if this looks good? @unclejack @SvenDowideit

@songgao Can you fix the DCO on your commit, please?
It's missing the > after your email address.

@unclejack Thanks for the catch! I've also rebased it to current master.

LGTM

ping @vieux @creack

LGTM