Johannes Schindelin [off-list ref] writes:
This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
remoter.bla.fetch. To avoid that, you have to use "git repo-config
remote.bla.fetch b ^$". (The last argument is a regular expression which
has to be matched by the value-to-be-oreplaced.)
Yup, one of the joys of working the config file everybody seems
to like ;-).
Hi,
On Sat, 25 Nov 2006, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
remoter.bla.fetch. To avoid that, you have to use "git repo-config
remote.bla.fetch b ^$". (The last argument is a regular expression which
has to be matched by the value-to-be-oreplaced.)
Yup, one of the joys of working the config file everybody seems to like
;-).
The problem is: config files are ubiquitous, so you need not teach
users about it. On the other hand, they are just key / value stores, i.e.
reflecting a mapping. What we want here, is a multimapping, so we use the
wrong tool.
But sometimes it is so much more pragmatic to just take off one shoe and
put the darned nail back into the wall than to go to the shop, buy the
hammer, go back, put the nail in, and try to sell the hammer via eBay.
BTW regarding your criticism of the config file: I agree that the write
support of git-repo-config was quite brittle at the start. Which is my
fault.
However, we had quite some flashing out bugs in the mean time, so I am
quite confident in the tool. Of course, what with the recent addition of a
user specific config file (which makes the name "repo-config" seem utterly
wrong), there might be some dragons in the code.
So, it seems that the whole config writing code is a perfect opportunity
for people wanting to audit source code!
Ciao,
Dscho