Johannes Schindelin [off-list ref] 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.
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