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

From: Junio C Hamano <junkio@cox.net>
Date: May 2, 2006, 08:59 UTC
Message-ID: <7v3bfsol9j.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>

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.

About the second one, I think it probably is a good idea to rename the "refspec used for fetch" as Sean suggested earlier. 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 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"

I am getting this out of the above:

        remote.ko.url . xxx.kernel.org:/pub/scm/git/git.git/
        remote.ko.pull ^$ master:refs/tags/ko-master
        remote.ko.pull ^$ next:refs/tags/ko-next
        remote.ko.pull ^$ +pu:refs/tags/ko-pu
        remote.ko.pull ^$ maint:refs/tags/ko-maint
        remote.ko.push ^$ heads/master
        remote.ko.push ^$ heads/next
        remote.ko.push ^$ +heads/pu
        remote.ko.push ^$ heads/maint

but I suspect that is not what you intended...

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.

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.