summaryrefslogtreecommitdiffstats
path: root/subcmds
diff options
context:
space:
mode:
authorKevin Degi <kdegi@codeaurora.org>2015-06-22 15:31:26 -0600
committerKevin Degi <kdegi@codeaurora.org>2015-07-15 15:53:14 +0000
commit679bac4bf3622412c29e8bca506bc670224d2e31 (patch)
tree08e61b881facf5795d24b173bf8a2adf69d5db55 /subcmds
parent185307d1dd1e63a8cf139c55f26895a6b378d43b (diff)
downloadgit-repo-679bac4bf3622412c29e8bca506bc670224d2e31.tar.gz
project.RemoteFetch: Handle depth cases more robustly
The fetch logic for the case where depth is set and revision is a SHA1 has several failure modes that are not handled well by the current logic. 1) 'git fetch <SHA1>' requires git version >= 1.8.3 2) 'git fetch <SHA1>' can be prevented by a configuration option on the server. 3) 'git fetch --depth=<N> <refspec>' can fail to contain a SHA1 specified by the manifest. Each of these cases cause infinite recursion when _RemoteFetch() tries to call itself with current_branch_only=False because current_branch_only is set to True when depth != None. To try to prevent the infinite recursion, we set self.clone_depth to None before the first retry of _RemoteFetch(). This will allow the Fetch to eventually succeed in the case where clone-depth is specified in the manifest. A user specified depth from the init command will still recurse infinitely. In addition, never try to fetch a SHA1 directly if the git version being used is not at least 1.8.3. Change-Id: I802fc17878c0929cfd63fff611633c1d3b54ecd3
Diffstat (limited to 'subcmds')
0 files changed, 0 insertions, 0 deletions