Add --no-history option to fetch and gclient for shallow clones.

fetch.py

Index: fetch.py
diff --git a/fetch.py b/fetch.py
index d3bcacd793195438a658cee1e03c7e83fbc70f93..897356f299c5aaaeff22b71f44c9259b3b24f867 100755
--- a/fetch.py
+++ b/fetch.py
@@ -114,6 +114,8 @@ class GclientGitCheckout(GclientCheckout, GitCheckout):
     sync_cmd = ['sync']
     if self.options.nohooks:
       sync_cmd.append('--nohooks')
+    if self.options.no_history:
+      sync_cmd.append('--no-history')
     if self.spec.get('with_branch_heads', False):
       sync_cmd.append('--with_branch_heads')
     self.run_gclient(*sync_cmd)
@@ -207,6 +209,7 @@ Valid options:
    -h, --help, help   Print this message.
    --nohooks          Don't run hooks after checkout.
    -n, --dry-run      Don't run commands, only print them.
+   --no-history       Perform shallow clones, don't fetch the full git history.
 """ % os.path.basename(sys.argv[0]))
   sys.exit(bool(msg))
 
@@ -220,6 +223,7 @@ def handle_args(argv):
 
   dry_run = False
   nohooks = False
+  no_history = False
   while len(argv) >= 2:

[iannucci, 2014/08/02 21:36:31]

this should really be using {arg,opt}parse...

[Primiano Tucci (use gerrit), 2014/08/03 17:43:34]

I stumbled upon this for a while as well. If I'm interpreting this right, I
think that the reason why this doesn't use optparse is because it is
intentionally striving of not swallowing the -- options after the recipe name,
to let the recipe script parse the remaining arguments on its own.
In other words, all this boilerplate seems to make it so that
$ fetch --foo recipe_name --bar
stops swallowing arguments @recipe_name, keeps --bar and passes it to the fetch
recipe. This is the reason (I think, I am just speculating here) why we can't
just use optparse here.

Having said that, I agree with you and looking at this code drives me nuts as
well.
My personal opinion is that we should rework this logic (here and in the fetch
recipes), use optparse just once (here) and pass all the parsed options to the
recipe (instead of having that re-run optparse  there). 

Rationale:
If I am interpreting everything correctly, all this logic here makes it so that:
$ fetch --nohooks chromium  # is valid
$ fetch chromium --nohooks # barfs with an error (because the chromium.py recipe
doesn't understand nohooks).

This is IMHO a terrible end-user experience. The only *benefit* that this brings
is decoupling the fetch vs. recipe arguments. At present state, a fetch recipe
could have its own --nohooks argument, with a completely different semantic,
allowing to invoke fetch --nohooks chromium --nohooks.

I'd just vote for simplicity, refactor recipes and fetch, use optparse only once
and rely on fetch recipes to not clash with the same global argument names used
by fetch. But I feel this should be part of another (slightly bigger) CL. 

     arg = argv[1]
     if not arg.startswith('-'):
@@ -229,6 +233,8 @@ def handle_args(argv):
       dry_run = True
     elif arg == '--nohooks':
       nohooks = True
+    elif arg == '--no-history':
+      no_history = True
     else:
       usage('Invalid option %s.' % arg)
 
@@ -241,7 +247,11 @@ def handle_args(argv):
 
   recipe = argv[1]
   props = argv[2:]
-  return optparse.Values({'dry_run':dry_run, 'nohooks':nohooks }), recipe, props
+  return (
+      optparse.Values(
+          {'dry_run':dry_run, 'nohooks':nohooks, 'no_history': no_history }),
+      recipe,
+      props)
 
 
 def run_recipe_fetch(recipe, props, aliased=False):