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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 2, 2006, 12:42 UTC
Message-ID: <Pine.LNX.4.63.0605021422520.7051@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v3bfsol9j.fsf@assigned-by-dhcp.cox.net>

Hi,

On Tue, 2 May 2006, Junio C Hamano wrote:

Show 10 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	This is what the patch series is all about.
> >
> > 	If there is no interest in a feature like this, let's just forget
> > 	about the whole "remote info in config" thing.
> 
> 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.

> About the second one, I think it probably is a good idea to
> rename the "refspec used for fetch" as Sean suggested earlier.

Okay.

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

Show 7 quoted lines

> I am not quite sure what this bit is about in the second one:
> 
>         sed -n \
>         -e "s/^URL: /remote.$name.url . /p" \
>         -e "s/^Pull: /remote.$name.pull ^$ /p" \
>         -e "s/^Push: /remote.$name.push ^$ /p" \
> 	< "$f"

That is obviously wrong. Will fix while refactoring.

> I think easy conversion tool is a good idea, but I would sleep
> better if it is outside of git-fetch/push chain and is available
> elsewhere, perhaps in contrib/ area.

Will do.

Show 7 quoted lines

> On a slightly related topic, I think my aversion to your "push
> remotes into config" series the last time was primarily because
> I do not trust repo-config.  Reading an already built config
> seems to work OK and I do not worry too much, but I am still
> wary of letting it write.  Typing "git repo-config" in a freshly
> initialized empty repository seems to segfault, which does not
> help my confidence level either.

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

I tried to make really sure that repo-config works as expected by introducing quite a few test cases into t1300, but evidently I forgot to check for things that do not usually break, like calling without arguments. This is fixed with the patch I just sent out.

This patch also introduces the "--get-regexp" flag to repo-config, which makes up for the lacking shell wildcards (you can ask questions like: which keys in the config end in "coatl"?).

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.

Ciao, Dscho