Junio C Hamano <[email protected]> writes:
> I couldn't quite get what you meant by "(but not the other way
> around)". Did you mean
>
> $ git push --force ../child2 refs/tags/*:refs/tags/*
>
> should not become non-forcing version because of the (lack of)
> prefix on the refspec does not trump the --force command line
> option? If so, making
>
> $ git push --no-force ../child2 +refs/tags/*:refs/tags/*
>
> not to force would make things more consistent, I suspect, i.e. we
> can simply declare that presence or absense of '+' prefix in the
> refspec determines the forced-ness of the push/fetch when there is
> no command line option to decide it, but an explicit command line
> option will always override it.
>
> Am I missing something obvious?
And of course I am missing the fact that --force and --no-force
controls a single boolean. If it controled a tristate (unspecified,
false, true), then what I wrote above makes tons of sense, but that
is not the reality. "git push --no-force" is saying the the same as
"git push", and its primarily reason for being there is to countermand
a "--force" that appears earlier on the command line for whatever
reason, e.g.
$ alias push='git push --force'
$ push --no-force ../child2 ...
So what you said in this patch 100% makes sense.
