git/Documentation/git-clone.txt, branch v2.13.2

clone: teach --recurse-submodules to optionally take a pathspec

2017-03-18T16:51:23Z

Teach clone --recurse-submodules to optionally take a pathspec argument which describes which submodules should be recursively initialized and cloned. If no pathspec is provided, --recurse-submodules will recursively initialize and clone all submodules by using a default pathspec of ".". In order to construct more complex pathspecs, --recurse-submodules can be given multiple times. This also configures the 'submodule.active' configuration option to be the given pathspec, such that any future invocation of `git submodule update` will keep up with the pathspec. Additionally the switch '--recurse' is removed from the Documentation as well as marked hidden in the options array, to streamline the options for submodules. A simple '--recurse' doesn't convey what is being recursed, e.g. it could mean directories or trees (c.f. ls-tree) In a lot of other commands we already have '--recurse-submodules' to mean recursing into submodules, so advertise this spelling here as the genuine option. Signed-off-by: Brandon Williams Signed-off-by: Junio C Hamano

Merge branch 'nd/shallow-deepen'

2016-10-10T21:03:50Z

The existing "git fetch --depth=" option was hard to use correctly when making the history of an existing shallow clone deeper. A new option, "--deepen=", has been added to make this easier to use. "git clone" also learned "--shallow-since=" and "--shallow-exclude=" options to make it easier to specify "I am interested only in the recent N months worth of history" and "Give me only the history since that version". * nd/shallow-deepen: (27 commits) fetch, upload-pack: --deepen=N extends shallow boundary by N commits upload-pack: add get_reachable_list() upload-pack: split check_unreachable() in two, prep for get_reachable_list() t5500, t5539: tests for shallow depth excluding a ref clone: define shallow clone boundary with --shallow-exclude fetch: define shallow boundary with --shallow-exclude upload-pack: support define shallow boundary by excluding revisions refs: add expand_ref() t5500, t5539: tests for shallow depth since a specific date clone: define shallow clone boundary based on time with --shallow-since fetch: define shallow boundary with --shallow-since upload-pack: add deepen-since to cut shallow repos based on time shallow.c: implement a generic shallow boundary finder based on rev-list fetch-pack: use a separate flag for fetch in deepening mode fetch-pack.c: mark strings for translating fetch-pack: use a common function for verbose printing fetch-pack: use skip_prefix() instead of starts_with() upload-pack: move rev-list code out of check_non_tip() upload-pack: make check_non_tip() clean things up on error upload-pack: tighten number parsing at "deepen" lines ...

clone: implement optional references

2016-08-15T22:28:45Z

In a later patch we want to try to create alternates for submodules, but they might not exist in the referenced superproject. So add a way to skip the non existing references and report them. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'sb/clone-shallow-passthru'

2016-07-06T20:38:13Z

Fix an unintended regression in v2.9 that breaks "clone --depth" that recurses down to submodules by forcing the submodules to also be cloned shallowly, which many server instances that host upstream of the submodules are not prepared for. * sb/clone-shallow-passthru: clone: do not let --depth imply --shallow-submodules

clone: do not let --depth imply --shallow-submodules

2016-06-20T18:35:28Z

In v2.9.0, we prematurely flipped the default to force cloning submodules shallowly, when the superproject is getting cloned shallowly. This is likely to fail when the upstream repositories submodules are cloned from a repository that is not prepared to serve histories that ends at a commit that is not at the tip of a branch, and we know the world is not yet ready. Use a safer default to clone the submodules fully, unless the user tells us that she knows that the upstream repository of the submodules are willing to cooperate with "--shallow-submodules" option. Noticed-by: Vadim Eisenberg Helped-by: Jeff King Helped-by: Stefan Beller Signed-off-by: Junio C Hamano

clone: define shallow clone boundary with --shallow-exclude

2016-06-13T21:38:16Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

clone: define shallow clone boundary based on time with --shallow-since

2016-06-13T21:38:16Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'sb/clone-shallow-passthru'

2016-05-06T21:45:43Z

"git clone" learned "--shallow-submodules" option. * sb/clone-shallow-passthru: clone: add `--shallow-submodules` flag

clone: add `--shallow-submodules` flag

2016-04-26T17:43:11Z

When creating a shallow clone of a repository with submodules, the depth argument does not influence the submodules, i.e. the submodules are done as non-shallow clones. It is unclear what the best default is for the depth of submodules of a shallow clone, so we need to have the possibility to do all kinds of combinations: * shallow super project with shallow submodules e.g. build bots starting always from scratch. They want to transmit the least amount of network data as well as using the least amount of space on their hard drive. * shallow super project with unshallow submodules e.g. The superproject is just there to track a collection of repositories and it is not important to have the relationship between the repositories intact. However the history of the individual submodules matter. * unshallow super project with shallow submodules e.g. The superproject is the actual project and the submodule is a library which is rarely touched. The new switch to select submodules to be shallow or unshallow supports all of these three cases. It is easy to transition from the first to the second case by just unshallowing the submodules (`git submodule foreach git fetch --unshallow`), but it is not possible to transition from the second to the first case (as we would have already transmitted the non shallow over the network). That is why we want to make the first case the default in case of a shallow super project. This leads to the inconvenience in the second case with the shallow super project and unshallow submodules, as you need to pass `--no-shallow-submodules`. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Merge branch 'sb/submodule-parallel-update'

2016-04-06T18:39:01Z

A major part of "git submodule update" has been ported to C to take advantage of the recently added framework to run download tasks in parallel. * sb/submodule-parallel-update: clone: allow an explicit argument for parallel submodule clones submodule update: expose parallelism to the user submodule helper: remove double 'fatal: ' prefix git submodule update: have a dedicated helper for cloning run_processes_parallel: rename parameters for the callbacks run_processes_parallel: treat output of children as byte array submodule update: direct error message to stderr fetching submodules: respect `submodule.fetchJobs` config option submodule-config: drop check against NULL submodule-config: keep update strategy around