Hi,
While working on a Perl module that parses git-style config files I noticed the following bug while replicating the --rename-section functionality:
spang@loki:~/tmp> cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[valid] foo = bar
hello = world
spang@loki:~/tmp> git config --get valid.foo
bar
spang@loki:~/tmp> git config --rename-section valid lost-data
spang@loki:~/tmp> cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[lost-data]
hello = worldAs you can see, --rename-section just replaces the entire line containing the section header that is being renamed, and if there is a config variable (or a comment, for that matter) following the section header on the same line (which is valid according to the config format documentation and the test suite), it is lost.
On further investigation, git config also blows away comments at the end of the line when replacing variable values, e.g.:
spang@loki:~/tmp> cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[test]
foo = bar ; a comment
spang@loki:~/tmp> git config test.foo baz
spang@loki:~/tmp> cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[test]
foo = bazIMHO, it would be saner to, when a section header or variable value is to be replaced, just replace the substring of the line in question that needs replacing, rather than writing whole new lines and having to check if there is a variable and/or a comment following the data that is being replaced and then writing those to new lines as well. (Where would the comment be moved to?)
I'm using git v1.6.3.1, but I've looked at the code and the bug is still present in HEAD.
cheers, Christine