Re: [PATCH 3/3] fetch: optionally store the current remote information in the config

From: Junio C Hamano <junkio@cox.net>
Date: May 3, 2006, 00:36 UTC
Message-ID: <7vmze0hrlj.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0605021422520.7051@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 7 quoted lines

>> Well, I took the liberty of adjusting the first one in the
>> series and tonight's "pu" has that one and the second one.
>> I haven't touched the third one yet, though.
>
> I don't think it is worth introducing yet another way to specify 
> short-cuts for remote information, if there is not at least one problem 
> which can get solved easier with it than with the other two ways.

I think the biggest contribution this series might bring in is to send a message that we would want to have things in config, not outside -- otherwise people might be tempted to do "while on this branch use this remote to fetch/pull from by default" outside config (perhaps abusing .git/branches, which _is_ per branch configuration).

Show 6 quoted lines

>> I do not like that hidden environment variable that sits in the
>> command I use everyday, waiting to be triggered to update my
>> .config file, possibly by my PEBCAK mistake when I did not want
>> it to do so.
>
> I will refactor it.

Thanks.

> I fixed this error (see separate patch). This was reintroduced by 
> carelessly checking argv[1] for "--list" and "-l", even if argc < 2.

Thanks.

> As for the trust in repo-config writing the config: it is all done by 
> calling git_config_set() or git_config_set_multivar(), which you use 
> yourself to set core.repositoryformatversion, among other values.

Since that happens in a freshly created empty config, I do not have to have a high confidence for that case, compared to the case it has to muck with random configuration files people already have populated with arbitrary gunk. In any case, I haven't seen breakage myself recently so hopefully it is safe enough now ;-).