Add --allow-dirty option to "git cl upload"

Add --allow-dirty option to "git cl upload" 

This is useful if you have minor local change that you don't
want to commit/upload and also don't want to stash (e.g.
if you are in the middle of the long build that relies on
the cl and also on some local mods).

[Sam Clegg, 2013-01-10 19:48:29]

https://codereview.chromium.org/11839002/diff/2001/git_cl.py
File git_cl.py (right):

https://codereview.chromium.org/11839002/diff/2001/git_cl.py#newcode1242
git_cl.py:1242: help='Allow upload even when there are uncommited changes')
I would have preferred to use --force here for this purpose (to match the
behaviour of git cl presubmit) but it looks like -f/force already has a slightly
different meaning here.

The current -f/force should really be called -y/--yes or --no-internactive I
guess...

https://codereview.chromium.org/11839002/diff/2001/git_cl.py#newcode1279
git_cl.py:1279: args.append('HEAD')
We most likely should just add 'HEAD' in all cases (as we never want to include
local change in the upload)... but there are a bunch of unit tests that check
args that break.  
Happy to update them too if you agree that "HEAD" always makes sense here? 
(HEAD might be slight speed improvement too as it doesn't need to stat all the
files in the local tree to generate the diff).

[M-A Ruel, 2013-01-10 22:53:21]

I think it goes against the spirit of the tool and that's much better to commit
all changes and pipeline them as needed. That said, I don't mind if it suits
your workflow.

In theory, I'd require a test but since I don't expect much usage from this
flag, I don't mind.

lgtm

[cmp, 2013-01-10 23:14:12]

sbc: Thanks, but let's not land this.  We should not support many corner cases
in our workflows and extensions of the tools.  It makes it hard to later update
our workflow to use some other tool.  This is an example of a small change that
adds another flag to git-cl that will slowly bifurcate our devs' usage of the
tools among those that use it and those that don't.

[Sam Clegg, 2013-01-10 23:54:11]

On 2013/01/10 23:14:12, cmp wrote:
> sbc: Thanks, but let's not land this.  We should not support many corner cases
> in our workflows and extensions of the tools.  It makes it hard to later
update
> our workflow to use some other tool.  This is an example of a small change
that
> adds another flag to git-cl that will slowly bifurcate our devs' usage of the
> tools among those that use it and those that don't.

Fair enough.  In all honesty it does seem like committing or stashing
is the right thing to do.  I'll figure out way to do one or the other.

BTW, what do you think about adding HEAD as a final arg to the git
calls in git cl.  While working on this change I noticed that we 
are relying on the working tree being clean and then doing
'git diff <upstream>' rather than 'git diff <upstream> HEAD'.  When
the tree is clean of course these produce the same results.  However
I think the former is always slower (especially on win32) as it has
to stat all files in the working tree.

On my windows machine there is a big difference:

$ time git diff HEAD^1 HEAD > /dev/null

real    0m0.109s
user    0m0.031s
sys     0m0.077s
$ time git diff HEAD^1 > /dev/null

real    0m2.012s
user    0m0.312s
sys     0m1.669s

Unless I'm wrong we *never* want to include changes from the working
tree so it should be marginally more correct too.

thoughts?

[cmp, 2013-01-10 23:59:14]

On 2013/01/10 23:54:11, Sam Clegg wrote:
> BTW, what do you think about adding HEAD as a final arg to the git
> calls in git cl.  While working on this change I noticed that we 
> are relying on the working tree being clean and then doing
> 'git diff <upstream>' rather than 'git diff <upstream> HEAD'.  When
> the tree is clean of course these produce the same results.  However
> I think the former is always slower (especially on win32) as it has
> to stat all files in the working tree.
> 
> On my windows machine there is a big difference:
> 
> $ time git diff HEAD^1 HEAD > /dev/null
> 
> real    0m0.109s
> user    0m0.031s
> sys     0m0.077s
> $ time git diff HEAD^1 > /dev/null
> 
> real    0m2.012s
> user    0m0.312s
> sys     0m1.669s
> 
> Unless I'm wrong we *never* want to include changes from the working
> tree so it should be marginally more correct too.
> 
> thoughts?

Diffing to HEAD SGTM.  Feel free to upload another review to make that change,
or file a bug and we can take a look at what's required.