{"thread":{"id":"31731","subject":"Re: Super long branch names corrupt `.git/config`","startedAt":"2012-10-04T17:15:25Z","lastAt":"2012-10-05T15:38:41Z","messageCount":6,"participants":["Junio C Hamano","Jeff King","Ben Olive","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200560","messageId":"CAAmo=1BU5N8nbonEb1aZEx=-e8VexwsE74pjm_56dXmCDK+K6g@mail.gmail.com","threadId":"31731","inReplyTo":null,"subject":"Super long branch names corrupt `.git/config`","fromName":"Ben Olive","fromEmail":"sionide21@gmail.com","sentAt":"2012-10-04T17:15:25Z","receivedAt":"2012-10-04T17:15:25Z","isPatch":false,"sender":{"key":"sionide21@gmail.com","avatar":null},"body":"My `.git/config` can be corrupted if I try to get a local branch with\nan extremely long name to track a remote branch.\n\nHere is a (contrived) example to reproduce the issue:\n\n\n    $ cd /tmp\n    $ mkdir buggyrepo otherrepo\n    $ cd buggyrepo/ && git init && cd -\n    $ cd otherrepo/ && git init && cd -\n    $ cd buggyrepo/\n    $ echo foo > MYFILE\n    $ git add MYFILE && git commit -m \"Initial\"\n    $ git remote add otherrepo ../otherrepo/\n    $ git checkout -b `ruby -e \"puts 'a'*200\"`\n    $ git push -u otherrepo `ruby -e \"puts 'a'*200\"`\n    fatal: bad config file line 11 in .git/config\n    $ git status\n    fatal: bad config file line 11 in .git/config\n\n\nWorkaround available: Just delete the offending entry.\n\nI tested this with 1.7.12.2\n\n--Ben Olive\n"},{"id":"200556","messageId":"20121004182946.GC2623@sigill.intra.peff.net","threadId":"31731","inReplyTo":"CAAmo=1BU5N8nbonEb1aZEx=-e8VexwsE74pjm_56dXmCDK+K6g@mail.gmail.com","subject":"Re: Super long branch names corrupt `.git/config`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-04T18:29:46Z","receivedAt":"2012-10-04T18:29:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 04, 2012 at 01:15:25PM -0400, Ben Olive wrote:\n\n> My `.git/config` can be corrupted if I try to get a local branch with\n> an extremely long name to track a remote branch.\n> \n> Here is a (contrived) example to reproduce the issue:\n> \n> \n>     $ cd /tmp\n>     $ mkdir buggyrepo otherrepo\n>     $ cd buggyrepo/ && git init && cd -\n>     $ cd otherrepo/ && git init && cd -\n>     $ cd buggyrepo/\n>     $ echo foo > MYFILE\n>     $ git add MYFILE && git commit -m \"Initial\"\n>     $ git remote add otherrepo ../otherrepo/\n>     $ git checkout -b `ruby -e \"puts 'a'*200\"`\n>     $ git push -u otherrepo `ruby -e \"puts 'a'*200\"`\n>     fatal: bad config file line 11 in .git/config\n>     $ git status\n>     fatal: bad config file line 11 in .git/config\n> \n> Workaround available: Just delete the offending entry.\n> \n> I tested this with 1.7.12.2\n\nThis is fixed by Ben Walton's 0971e99 (Remove the hard coded length\nlimit on variable names in config files, 2012-09-30). Not sure yet\nwhether it will make it into v1.8.0 or not.\n\nHowever, note that the tracking config is only one limit to branch name\nlength. On many filesystems, you are limited to 256 bytes (or some other\nnumber) per path component, and writing to \"refs/heads/aaa{256}.lock\"\nwill fail.\n\n-Peff\n"},{"id":"200537","messageId":"7v391uyr2w.fsf@alter.siamese.dyndns.org","threadId":"31731","inReplyTo":"CAAmo=1BU5N8nbonEb1aZEx=-e8VexwsE74pjm_56dXmCDK+K6g@mail.gmail.com","subject":"Re: Super long branch names corrupt `.git/config`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T19:28:39Z","receivedAt":"2012-10-04T19:28:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ben Olive <sionide21@gmail.com> writes:\n\n> My `.git/config` can be corrupted if I try to get a local branch with\n> an extremely long name to track a remote branch.\n>\n> Here is a (contrived) example to reproduce the issue:\n\nDon't do that, then ;-)\n\nI think we have a change that is already cooking.\n\nBen (Walton), want to add a test for your 0971e99 (Remove the hard\ncoded length limit on variable names in config files, 2012-09-30)\nbefore it hits 'next', perhaps?\n"},{"id":"200577","messageId":"20121005002942.GB17586@sigill.intra.peff.net","threadId":"31731","inReplyTo":"7v391uyr2w.fsf@alter.siamese.dyndns.org","subject":"Re: Super long branch names corrupt `.git/config`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-05T00:29:42Z","receivedAt":"2012-10-05T00:29:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 04, 2012 at 12:28:39PM -0700, Junio C Hamano wrote:\n\n> Ben Olive <sionide21@gmail.com> writes:\n> \n> > My `.git/config` can be corrupted if I try to get a local branch with\n> > an extremely long name to track a remote branch.\n> >\n> > Here is a (contrived) example to reproduce the issue:\n> \n> Don't do that, then ;-)\n> \n> I think we have a change that is already cooking.\n> \n> Ben (Walton), want to add a test for your 0971e99 (Remove the hard\n> coded length limit on variable names in config files, 2012-09-30)\n> before it hits 'next', perhaps?\n\nI came up with this test earlier today when responding in this thread:\n\ndiff --git a/t/t7201-co.sh b/t/t7201-co.sh\nindex be9672e..a32ecd9 100755\n--- a/t/t7201-co.sh\n+++ b/t/t7201-co.sh\n@@ -454,6 +454,11 @@ test_expect_success \\\n     'checkout with --track, but without -b, fails with too short tracked name' '\n     test_must_fail git checkout --track renamer'\n \n+test_expect_success 'checkout tracking with long branch name' '\n+\tz200=$_z40$_z40$_z40$_z40$_z40\n+\tgit checkout --track -b foo-$z200\n+'\n+\n setup_conflicting_index () {\n \trm -f .git/index &&\n \tO=$(echo original | git hash-object -w --stdin) &&\n\nbut it feels a little fake. Why 200? Because that will test the config\nlimit, but will not overflow the NAME_MAX limit (at least not on\nLinux! No clue on other platforms) when we try to create\nrefs/heads/foo-$z200.\n\nSo while this is a nice concrete user-visible impact of Ben's patch, I\nthink it is a little flaky to be testing. We should probably have a\nstraight config test in t1303, though.\n\n-Peff\n"},{"id":"200578","messageId":"CAH5451=fEDd+EvgEst_G00nQ-yot+2UCbWt_UpduR57bhxHYew@mail.gmail.com","threadId":"31731","inReplyTo":"20121005002942.GB17586@sigill.intra.peff.net","subject":"Re: Super long branch names corrupt `.git/config`","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-10-05T00:36:52Z","receivedAt":"2012-10-05T00:36:52Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 5 October 2012 10:29, Jeff King <peff@peff.net> wrote:\n>...\n>\n>but it feels a little fake. Why 200? Because that will test the config\n>limit, but will not overflow the NAME_MAX limit (at least not on\n>Linux! No clue on other platforms) when we try to create\n>refs/heads/foo-$z200.\n\nI can't test this particular case right now, but I recently had an\nissue with Windows Server 2008 due to a long filename, that\nessentially meant I couldn't move, change owner or change permissions\non the given file. Unless someone has more info I can test a bit\nlater. Is the idea that we shouldn't allow filenames that will cause\nissues with the underlying OS (or other people's OS) or something\nelse?\n\nRegards,\n\nAndrew Ardill\n"},{"id":"200630","messageId":"20121005153841.GB24957@sigill.intra.peff.net","threadId":"31731","inReplyTo":"CAH5451=fEDd+EvgEst_G00nQ-yot+2UCbWt_UpduR57bhxHYew@mail.gmail.com","subject":"Re: Super long branch names corrupt `.git/config`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-05T15:38:41Z","receivedAt":"2012-10-05T15:38:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 05, 2012 at 10:36:52AM +1000, Andrew Ardill wrote:\n\n> On 5 October 2012 10:29, Jeff King <peff@peff.net> wrote:\n> >...\n> >\n> >but it feels a little fake. Why 200? Because that will test the config\n> >limit, but will not overflow the NAME_MAX limit (at least not on\n> >Linux! No clue on other platforms) when we try to create\n> >refs/heads/foo-$z200.\n> \n> I can't test this particular case right now, but I recently had an\n> issue with Windows Server 2008 due to a long filename, that\n> essentially meant I couldn't move, change owner or change permissions\n> on the given file. Unless someone has more info I can test a bit\n> later. Is the idea that we shouldn't allow filenames that will cause\n> issues with the underlying OS (or other people's OS) or something\n> else?\n\nI don't think it's that we shouldn't allow such filenames. It's only\nthat the test is flaky, because making the branch name long enough to\ntest the relaxed config code means that we may run afoul of filesystem\nlimitations on creating the ref itself.\n\nIt's a separate issue whether we should restrict the length of branch\nnames in order to protect against filesystem limits. I tend to think\nnot, as we handle the filesystem error just fine. The only reason to do\nso would be to protect people on multi-system projects (e.g., you make a\nlong branch name on Linux that cannot be fetched to a Windows system. Or\nsomething; I did not check the limits for those systems). But I have\nnever heard of that happening in practice, so I think we can ignore it\nfor now.\n\n-Peff\n"}]}