{"thread":{"id":"48167","subject":"Bug: duplicate sections in .git/config after remote removal","startedAt":"2018-03-27T20:41:51Z","lastAt":"2018-03-28T16:34:53Z","messageCount":8,"participants":["Jason Frey","Stefan Beller","Ævar Arnfjörð Bjarmason","Philip Oakley","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"343168","messageId":"CAP6Vx84GRRxgMZF5P6tb6F4rJ8ozxx-d0o_LsNe=kEYVRkBTKQ@mail.gmail.com","threadId":"48167","inReplyTo":null,"subject":"Bug: duplicate sections in .git/config after remote removal","fromName":"Jason Frey","fromEmail":"jfrey@redhat.com","sentAt":"2018-03-27T20:41:24Z","receivedAt":"2018-03-27T20:41:51Z","isPatch":false,"sender":{"key":"jfrey@redhat.com","avatar":null},"body":"While the impact of this bug is minimal, and git itself is not\naffected, it can affect external tools that want to read the\n.git/config file, expecting unique section names.\n\nTo reproduce:\n\nGiven the following example .git/config file (I am leaving out the\n[core] section for brevity):\n\n    [remote \"origin\"]\n        url = git@github.com:Fryguy/example.git\n        fetch = +refs/heads/*:refs/remotes/origin/*\n    [branch \"master\"]\n        remote = origin\n        merge = refs/heads/master\n\nRunning `git remote rm origin` will result in the following contents:\n\n    [branch \"master\"]\n\nRunning `git remote add origin git@github.com:Fryguy/example.git` will\nresult in the following contents:\n\n    [branch \"master\"]\n    [remote \"origin\"]\n        url = git@github.com:Fryguy/example.git\n        fetch = +refs/heads/*:refs/remotes/origin/*\n\nAnd finally, running `git fetch origin; git branch -u origin/master`\nwill result in the following contents:\n\n    [branch \"master\"]\n    [remote \"origin\"]\n        url = git@github.com:Fryguy/example.git\n        fetch = +refs/heads/*:refs/remotes/origin/*\n    [branch \"master\"]\n        remote = origin\n        merge = refs/heads/master\n\nat which point you can see the duplicate sections (even though one is\nempty).  Also note that if you do the steps again, you will be left\nwith 3 sections, 2 of which are empty.  This process can be repeated\nover and over.\n\nThanks,\nJason\n"},{"id":"343177","messageId":"CAGZ79ka_dd=4-EVmoKrBVC_y4+eVPSz959BVNmzZkOwiZh_24A@mail.gmail.com","threadId":"48167","inReplyTo":"CAP6Vx84GRRxgMZF5P6tb6F4rJ8ozxx-d0o_LsNe=kEYVRkBTKQ@mail.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-03-27T21:45:15Z","receivedAt":"2018-03-27T21:46:01Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Mar 27, 2018 at 1:41 PM Jason Frey <jfrey@redhat.com> wrote:\n\n> at which point you can see the duplicate sections (even though one is\n> empty).  Also note that if you do the steps again, you will be left\n> with 3 sections, 2 of which are empty.  This process can be repeated\n> over and over.\n\nI agree that this is an issue for the user, and there were some attempts\nto fix it in the past. (feel free to dig them up in the archive at\nhttps://public-inbox.org/git)\n\nIIRC the problem is (a) with the loose file format (What if the user put\na valuable comment just after or before the '[branch \"master\"]' line?)\nas well as (b) the way the parser/writer works (single pass, line by line)\n\n(b) specifically made it a \"huge effort, but little return\" bug,\nso nobody got around for a proper fix.\n\nThanks,\nStefan\n"},{"id":"343178","messageId":"87r2o5w5mn.fsf@evledraar.gmail.com","threadId":"48167","inReplyTo":"CAP6Vx84GRRxgMZF5P6tb6F4rJ8ozxx-d0o_LsNe=kEYVRkBTKQ@mail.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-03-27T21:49:52Z","receivedAt":"2018-03-27T21:50:02Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Mar 27 2018, Jason Frey wrote:\n\n> While the impact of this bug is minimal, and git itself is not\n> affected, it can affect external tools that want to read the\n> .git/config file, expecting unique section names.\n>\n> To reproduce:\n>\n> Given the following example .git/config file (I am leaving out the\n> [core] section for brevity):\n>\n>     [remote \"origin\"]\n>         url = git@github.com:Fryguy/example.git\n>         fetch = +refs/heads/*:refs/remotes/origin/*\n>     [branch \"master\"]\n>         remote = origin\n>         merge = refs/heads/master\n>\n> Running `git remote rm origin` will result in the following contents:\n>\n>     [branch \"master\"]\n>\n> Running `git remote add origin git@github.com:Fryguy/example.git` will\n> result in the following contents:\n>\n>     [branch \"master\"]\n>     [remote \"origin\"]\n>         url = git@github.com:Fryguy/example.git\n>         fetch = +refs/heads/*:refs/remotes/origin/*\n>\n> And finally, running `git fetch origin; git branch -u origin/master`\n> will result in the following contents:\n>\n>     [branch \"master\"]\n>     [remote \"origin\"]\n>         url = git@github.com:Fryguy/example.git\n>         fetch = +refs/heads/*:refs/remotes/origin/*\n>     [branch \"master\"]\n>         remote = origin\n>         merge = refs/heads/master\n>\n> at which point you can see the duplicate sections (even though one is\n> empty).  Also note that if you do the steps again, you will be left\n> with 3 sections, 2 of which are empty.  This process can be repeated\n> over and over.\n\nThis can be annoying and result in some very verbose config files when\nwe automatically edit them, e.g.:\n\n    (rm -v /tmp/test.ini; for i in {1..3}; do git config -f /tmp/test.ini foo.bar 0 && git config -f /tmp/test.ini --unset foo.bar; done; cat /tmp/test.ini)\n    removed '/tmp/test.ini'\n    [foo]\n    [foo]\n    [foo]\n\nBut it's not so clear that it should be called a bug, yes we could be a\nbit smarter and not add obvious crap like the example above (duplicate\nsections at the end), but it gets less obvious in more complex cases,\nsee my c8b2cec09e (\"branch: add test for -m renaming multiple config\nsections\", 2017-06-18) for one such example.\n\nGit has a config format that's hybrid human/machine editable. Consider a\ncase like:\n\n    [gc]\n    ;; Here's all the gc config we set up to avoid the great outage of 2015\n    autoDetach = false\n    ;; Our aliases\n    [alias]\n    st = status\n\nNow, if I run `git config gc.auto 0` is it better if we end up with:\n\n    [gc]\n    ;; Here's all the gc config we set up to avoid the great outage of 2015\n    autoDetach = false\n    auto = 0\n    ;; Our aliases\n    [alias]\n    st = status\n\nOr something that makes it more clear that a machine added something at\nthe end:\n\n    [gc]\n    ;; Here's all the gc config we set up to avoid the great outage of 2015\n    autoDetach = false\n    ;; Our aliases\n    [alias]\n    st = status\n    [gc]\n    auto = 0\n\nMost importantly though, regardless of what we decide to do when we\nmachine-edit the file, it's also human-editable, and being able to\nrepeat sections is part of our config format that you're simply going to\nhave to deal with.\n\nThe external tool (presumably some generic *.ini parser) you're trying\nto point at git's config is broken for that purpose if it doesn't handle\nduplicate sections. You're probably better off trying to parse `git\nconfig --list --null` than trying to make it work.\n\nI don't think we'd ever want to get rid of this feature, it's *very*\nuseful. Both for config via the include macro, and for people to\nmanually paste some config they want to try out to the end of their\nconfig, without having to manually edit it to incorporate it into their\nalready existing sections.\n"},{"id":"343211","messageId":"EBC18DF9AA474D29B3178885F122D962@PhilipOakley","threadId":"48167","inReplyTo":"87r2o5w5mn.fsf@evledraar.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-03-28T08:06:15Z","receivedAt":"2018-03-28T08:07:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n> On Tue, Mar 27 2018, Jason Frey wrote:\n>\n>> While the impact of this bug is minimal, and git itself is not\n>> affected, it can affect external tools that want to read the\n>> .git/config file, expecting unique section names.\n>>\n>> To reproduce:\n>>\n>> Given the following example .git/config file (I am leaving out the\n>> [core] section for brevity):\n>>\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> Running `git remote rm origin` will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>\n>> Running `git remote add origin git@github.com:Fryguy/example.git` will\n>> result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> And finally, running `git fetch origin; git branch -u origin/master`\n>> will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> at which point you can see the duplicate sections (even though one is\n>> empty).  Also note that if you do the steps again, you will be left\n>> with 3 sections, 2 of which are empty.  This process can be repeated\n>> over and over.\n>\n> This can be annoying and result in some very verbose config files when\n> we automatically edit them, e.g.:\n>\n>    (rm -v /tmp/test.ini; for i in {1..3}; do git config -f /tmp/test.ini\n> foo.bar 0 && git config -f /tmp/test.ini --unset foo.bar; done; cat\n> /tmp/test.ini)\n>    removed '/tmp/test.ini'\n>    [foo]\n>    [foo]\n>    [foo]\n>\n> But it's not so clear that it should be called a bug, yes we could be a\n> bit smarter and not add obvious crap like the example above (duplicate\n> sections at the end), but it gets less obvious in more complex cases,\n> see my c8b2cec09e (\"branch: add test for -m renaming multiple config\n> sections\", 2017-06-18) for one such example.\n>\n> Git has a config format that's hybrid human/machine editable. Consider a\n> case like:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Now, if I run `git config gc.auto 0` is it better if we end up with:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    auto = 0\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Or something that makes it more clear that a machine added something at\n> the end:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>    [gc]\n>    auto = 0\n>\n> Most importantly though, regardless of what we decide to do when we\n> machine-edit the file, it's also human-editable, and being able to\n> repeat sections is part of our config format that you're simply going to\n> have to deal with.\n\nOne option may be to create  a simple 'lint' style checker that simply\nhiughlights and suggests options so the user can decide for themselves what\nthey need to do. This would help span the gap between hard format and the\nsoft format capabiulities of machine readable ini files, the Git config\nreader and being human readable.\n\nThus duplicate sections would be noted, likewise the presence of comments\nimmediately preceding a section header, or terminating a section (with or\nwithout spacing?), etc.Such a config_lint could reside in the contrib as a\nsupprt tool, and may in the long term be a guide to a common format.\nHowever, as noted, it would be more of a long term aspiration..\n\n\n>\n> The external tool (presumably some generic *.ini parser) you're trying\n> to point at git's config is broken for that purpose if it doesn't handle\n> duplicate sections. You're probably better off trying to parse `git\n> config --list --null` than trying to make it work.\n>\n> I don't think we'd ever want to get rid of this feature, it's *very*\n> useful. Both for config via the include macro, and for people to\n> manually paste some config they want to try out to the end of their\n> config, without having to manually edit it to incorporate it into their\n> already existing sections.\n>\n\n--\nPhilip\n\n"},{"id":"343212","messageId":"D4DCD9C1E17B4AD5AFB501B8FADA02BB@PhilipOakley","threadId":"48167","inReplyTo":"87r2o5w5mn.fsf@evledraar.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-03-28T07:54:09Z","receivedAt":"2018-03-28T08:08:12Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n> On Tue, Mar 27 2018, Jason Frey wrote:\n>\n>> While the impact of this bug is minimal, and git itself is not\n>> affected, it can affect external tools that want to read the\n>> .git/config file, expecting unique section names.\n>>\n>> To reproduce:\n>>\n>> Given the following example .git/config file (I am leaving out the\n>> [core] section for brevity):\n>>\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> Running `git remote rm origin` will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>\n>> Running `git remote add origin git@github.com:Fryguy/example.git` will\n>> result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> And finally, running `git fetch origin; git branch -u origin/master`\n>> will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> at which point you can see the duplicate sections (even though one is\n>> empty).  Also note that if you do the steps again, you will be left\n>> with 3 sections, 2 of which are empty.  This process can be repeated\n>> over and over.\n>\n> This can be annoying and result in some very verbose config files when\n> we automatically edit them, e.g.:\n>\n>    (rm -v /tmp/test.ini; for i in {1..3}; do git config -f /tmp/test.ini \n> foo.bar 0 && git config -f /tmp/test.ini --unset foo.bar; done; cat \n> /tmp/test.ini)\n>    removed '/tmp/test.ini'\n>    [foo]\n>    [foo]\n>    [foo]\n>\n> But it's not so clear that it should be called a bug, yes we could be a\n> bit smarter and not add obvious crap like the example above (duplicate\n> sections at the end), but it gets less obvious in more complex cases,\n> see my c8b2cec09e (\"branch: add test for -m renaming multiple config\n> sections\", 2017-06-18) for one such example.\n>\n> Git has a config format that's hybrid human/machine editable. Consider a\n> case like:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Now, if I run `git config gc.auto 0` is it better if we end up with:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    auto = 0\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Or something that makes it more clear that a machine added something at\n> the end:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>    [gc]\n>    auto = 0\n>\n> Most importantly though, regardless of what we decide to do when we\n> machine-edit the file, it's also human-editable, and being able to\n> repeat sections is part of our config format that you're simply going to\n> have to deal with.\n\nOne option may be to create  a simple 'lint' style checker that simply \nhiughlights and suggests options so the user can decide for themselves what \nthey need to do. This would help span the gap between hard format and the \nsoft format capabiulities of machine readable ini files, the Git config \nreader and being human readable.\n\nThus duplicate sections would be noted, likewise the presence of comments \nimmediately preceding a section header, or terminating a section (with or \nwithout spacing?), etc.Such a config_lint could reside in the contrib as a \nsupprt tool, and may in the long term be a guide to a common format. \nHowever, as noted, it would be more of a long term aspiration..\n\n\n>\n> The external tool (presumably some generic *.ini parser) you're trying\n> to point at git's config is broken for that purpose if it doesn't handle\n> duplicate sections. You're probably better off trying to parse `git\n> config --list --null` than trying to make it work.\n>\n> I don't think we'd ever want to get rid of this feature, it's *very*\n> useful. Both for config via the include macro, and for people to\n> manually paste some config they want to try out to the end of their\n> config, without having to manually edit it to incorporate it into their\n> already existing sections.\n>\n\n--\nPhilip \n\n"},{"id":"343213","messageId":"3E6DC98AE44C424E9D97A08E0522EF5B@PhilipOakley","threadId":"48167","inReplyTo":"87r2o5w5mn.fsf@evledraar.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-03-28T07:54:54Z","receivedAt":"2018-03-28T08:09:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n> On Tue, Mar 27 2018, Jason Frey wrote:\n>\n>> While the impact of this bug is minimal, and git itself is not\n>> affected, it can affect external tools that want to read the\n>> .git/config file, expecting unique section names.\n>>\n>> To reproduce:\n>>\n>> Given the following example .git/config file (I am leaving out the\n>> [core] section for brevity):\n>>\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> Running `git remote rm origin` will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>\n>> Running `git remote add origin git@github.com:Fryguy/example.git` will\n>> result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> And finally, running `git fetch origin; git branch -u origin/master`\n>> will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> at which point you can see the duplicate sections (even though one is\n>> empty).  Also note that if you do the steps again, you will be left\n>> with 3 sections, 2 of which are empty.  This process can be repeated\n>> over and over.\n>\n> This can be annoying and result in some very verbose config files when\n> we automatically edit them, e.g.:\n>\n>    (rm -v /tmp/test.ini; for i in {1..3}; do git config -f /tmp/test.ini \n> foo.bar 0 && git config -f /tmp/test.ini --unset foo.bar; done; cat \n> /tmp/test.ini)\n>    removed '/tmp/test.ini'\n>    [foo]\n>    [foo]\n>    [foo]\n>\n> But it's not so clear that it should be called a bug, yes we could be a\n> bit smarter and not add obvious crap like the example above (duplicate\n> sections at the end), but it gets less obvious in more complex cases,\n> see my c8b2cec09e (\"branch: add test for -m renaming multiple config\n> sections\", 2017-06-18) for one such example.\n>\n> Git has a config format that's hybrid human/machine editable. Consider a\n> case like:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Now, if I run `git config gc.auto 0` is it better if we end up with:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    auto = 0\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Or something that makes it more clear that a machine added something at\n> the end:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>    [gc]\n>    auto = 0\n>\n> Most importantly though, regardless of what we decide to do when we\n> machine-edit the file, it's also human-editable, and being able to\n> repeat sections is part of our config format that you're simply going to\n> have to deal with.\n\nOne option may be to create  a simple 'lint' style checker that simply \nhiughlights and suggests options so the user can decide for themselves what \nthey need to do. This would help span the gap between hard format and the \nsoft format capabiulities of machine readable ini files, the Git config \nreader and being human readable.\n\nThus duplicate sections would be noted, likewise the presence of comments \nimmediately preceding a section header, or terminating a section (with or \nwithout spacing?), etc.Such a config_lint could reside in the contrib as a \nsupprt tool, and may in the long term be a guide to a common format. \nHowever, as noted, it would be more of a long term aspiration..\n\n\n>\n> The external tool (presumably some generic *.ini parser) you're trying\n> to point at git's config is broken for that purpose if it doesn't handle\n> duplicate sections. You're probably better off trying to parse `git\n> config --list --null` than trying to make it work.\n>\n> I don't think we'd ever want to get rid of this feature, it's *very*\n> useful. Both for config via the include macro, and for people to\n> manually paste some config they want to try out to the end of their\n> config, without having to manually edit it to incorporate it into their\n> already existing sections.\n>\n\n--\nPhilip \n\n"},{"id":"343214","messageId":"113DAB1F68404779AB7B5899171AC13E@PhilipOakley","threadId":"48167","inReplyTo":"87r2o5w5mn.fsf@evledraar.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-03-28T07:55:22Z","receivedAt":"2018-03-28T08:18:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n> On Tue, Mar 27 2018, Jason Frey wrote:\n>\n>> While the impact of this bug is minimal, and git itself is not\n>> affected, it can affect external tools that want to read the\n>> .git/config file, expecting unique section names.\n>>\n>> To reproduce:\n>>\n>> Given the following example .git/config file (I am leaving out the\n>> [core] section for brevity):\n>>\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> Running `git remote rm origin` will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>\n>> Running `git remote add origin git@github.com:Fryguy/example.git` will\n>> result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>\n>> And finally, running `git fetch origin; git branch -u origin/master`\n>> will result in the following contents:\n>>\n>>     [branch \"master\"]\n>>     [remote \"origin\"]\n>>         url = git@github.com:Fryguy/example.git\n>>         fetch = +refs/heads/*:refs/remotes/origin/*\n>>     [branch \"master\"]\n>>         remote = origin\n>>         merge = refs/heads/master\n>>\n>> at which point you can see the duplicate sections (even though one is\n>> empty).  Also note that if you do the steps again, you will be left\n>> with 3 sections, 2 of which are empty.  This process can be repeated\n>> over and over.\n>\n> This can be annoying and result in some very verbose config files when\n> we automatically edit them, e.g.:\n>\n>    (rm -v /tmp/test.ini; for i in {1..3}; do git config -f /tmp/test.ini \n> foo.bar 0 && git config -f /tmp/test.ini --unset foo.bar; done; cat \n> /tmp/test.ini)\n>    removed '/tmp/test.ini'\n>    [foo]\n>    [foo]\n>    [foo]\n>\n> But it's not so clear that it should be called a bug, yes we could be a\n> bit smarter and not add obvious crap like the example above (duplicate\n> sections at the end), but it gets less obvious in more complex cases,\n> see my c8b2cec09e (\"branch: add test for -m renaming multiple config\n> sections\", 2017-06-18) for one such example.\n>\n> Git has a config format that's hybrid human/machine editable. Consider a\n> case like:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Now, if I run `git config gc.auto 0` is it better if we end up with:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    auto = 0\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>\n> Or something that makes it more clear that a machine added something at\n> the end:\n>\n>    [gc]\n>    ;; Here's all the gc config we set up to avoid the great outage of 2015\n>    autoDetach = false\n>    ;; Our aliases\n>    [alias]\n>    st = status\n>    [gc]\n>    auto = 0\n>\n> Most importantly though, regardless of what we decide to do when we\n> machine-edit the file, it's also human-editable, and being able to\n> repeat sections is part of our config format that you're simply going to\n> have to deal with.\n\nOne option may be to create  a simple 'lint' style checker that simply \nhiughlights and suggests options so the user can decide for themselves what \nthey need to do. This would help span the gap between hard format and the \nsoft format capabiulities of machine readable ini files, the Git config \nreader and being human readable.\n\nThus duplicate sections would be noted, likewise the presence of comments \nimmediately preceding a section header, or terminating a section (with or \nwithout spacing?), etc.Such a config_lint could reside in the contrib as a \nsupprt tool, and may in the long term be a guide to a common format. \nHowever, as noted, it would be more of a long term aspiration..\n\n\n>\n> The external tool (presumably some generic *.ini parser) you're trying\n> to point at git's config is broken for that purpose if it doesn't handle\n> duplicate sections. You're probably better off trying to parse `git\n> config --list --null` than trying to make it work.\n>\n> I don't think we'd ever want to get rid of this feature, it's *very*\n> useful. Both for config via the include macro, and for people to\n> manually paste some config they want to try out to the end of their\n> config, without having to manually edit it to incorporate it into their\n> already existing sections.\n>\n\n--\nPhilip \n\n"},{"id":"343224","messageId":"nycvar.QRO.7.76.6.1803281110260.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"48167","inReplyTo":"CAGZ79ka_dd=4-EVmoKrBVC_y4+eVPSz959BVNmzZkOwiZh_24A@mail.gmail.com","subject":"Re: Bug: duplicate sections in .git/config after remote removal","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-28T16:34:34Z","receivedAt":"2018-03-28T16:34:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan & Jason,\n\nOn Tue, 27 Mar 2018, Stefan Beller wrote:\n\n> On Tue, Mar 27, 2018 at 1:41 PM Jason Frey <jfrey@redhat.com> wrote:\n> \n> > at which point you can see the duplicate sections (even though one is\n> > empty).  Also note that if you do the steps again, you will be left\n> > with 3 sections, 2 of which are empty.  This process can be repeated\n> > over and over.\n> \n> I agree that this is an issue for the user, and there were some attempts\n> to fix it in the past. (feel free to dig them up in the archive at\n> https://public-inbox.org/git)\n\nNote: as far as I remember, the attempted fixes were exclusively trying to\nremove the empty section. But this report suggests that we could instead\n*keep* empty sections, but then reuse them when a new value is added.\n\n> IIRC the problem is (a) with the loose file format (What if the user put\n> a valuable comment just after or before the '[branch \"master\"]' line?)\n> as well as (b) the way the parser/writer works (single pass, line by line)\n> \n> (b) specifically made it a \"huge effort, but little return\" bug,\n> so nobody got around for a proper fix.\n\nYes, (a) makes removing an empty section something less of a desirable\nthing. Unless there are no comments before and after the section, of\ncourse, and yes, (b) is a real thing.\n\nOn a positive note: I just finished work on a set of patches addressing\nthis:\nhttps://github.com/git/git/compare/master...dscho:empty-config-section (I\nplan on submitting this tomorrow)\n\nCiao,\nDscho\n"}]}