Junio C Hamano <gitster@xxxxxxxxx> 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.
