Re: [PATCH 3/8] push tests: add more testing for forced tag pushing

From: Junio C Hamano <gitster@pobox.com>
Date: May 8, 2018, 03:19 UTC
Message-ID: <xmqq4ljiomvv.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <xmqq8t8uoovn.fsf@gitster-ct.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 quoted lines

> 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.