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

Hi,

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

Johannes Schindelin [off-list ref] writes:

quoted

	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.

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.

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