Junio C Hamano <gitster@xxxxxxxxx> writes: > clone.defaultremotename is a single valued configuration variable, > and this correctly implements the "last one wins" behaviour (but > previous remote_name will leak every time clone.defaultremotename > is seen in the config stream). Great catch - fixed for v2. > I thought the whole point of doing the write_config() was so that > anything came from the command line option can be written back to the > configuration file, so I am not sure what the harm would be to update > remote_name from the configuration whether option_origin is used or > not here. Perhaps add "clone.defaultremotename" to the set of > configuration setting write_config() uses, when --option is given from > the command line, and remove this special case? That's true! The special case was there mostly to keep --origin as the highest priority, but that can be solved much more naturally by moving the assignment from option_origin to remote_name down below the second git_config call. Included in v2. Sean
