On Tue, Jan 28, 2020 at 02:11:01PM -0800, Junio C Hamano wrote: > > push.default:: > > Defines the action `git push` should take if no refspec is > > - explicitly given. Different values are well-suited for > > - specific workflows; for instance, in a purely central workflow > > - (i.e. the fetch source is equal to the push destination), > > - `upstream` is probably what you want. Possible values are: > > + neither explicitly (on the command-line) nor implicitly (via a > > + `remote.*.push` config option) given. Different values are > > + well-suited for specific workflows; for instance, in a purely > > + central workflow (i.e. the fetch source is equal to the push > > + destination), `upstream` is probably what you want. Possible > > + values are: > > + > > -- > > Hmph, I am not sure the act of deliberately setting remote.*.push > configuration should not count as an explicit request to Git the > user makes. > > Immediately follows the above, the description of one of the > possible values read thusly: > > * `nothing` - do not push anything (error out) unless a refspec is > explicitly given. This is primarily meant for people who want to > avoid mistakes by always being explicit. > > which may need an adjustment to keep the whole coherent. Yeah, you're right. The term "explicit" gets thrown around a fair bit there. In that sense my original was slightly better, in that it defines "explicit" (one might say it even does so...explicitly). But... > If we have to change anything in the description, I would say that > we can just drop "explicitly". [...] Yes, I like dropping that word even better. Though I'd still slightly worry that somebody might not consider configured refspecs. Saying more clearly "any refspec no matter where it comes from" might still be worthwhile. I.e., something like: Defines the action `git push` should take if no refspec is given (whether from the command-line, config, or elsewhere). ? -Peff
